NTIA/SigMF lags gnuradio/SigMF

[aromanielloNTIA]

It looks like SCOS Actions' use of NTIA/SigMF instead of the official gnuradio/SigMF is a relic from a time before NTIA/sigmf-ns-ntia existed. The official SigMF has a v1.0.0 release, which we should be using instead of an unmaintained and out-of-date fork.

This will also make the SigMF dependency installable from PyPi along with most other dependencies, which should speed up SCOS build times a little bit, since it's one fewer package that will need to be built from source.

[aromanielloNTIA]

The release page for gnuradio/SigMF v1.0.0 indicates backwards compatibility. This shouldn't be a difficult switch (maybe just increment the version number?), and I don't get any errors from crudely changing the dependency to gnuradio/SigMF 1.0.0.

[aromanielloNTIA]

There appear to be incompatibilities due to the changes made on the multi-recording-archive branch of NTIA/SigMF. I do actually get an error when running gnuradio/SigMF 1.0.0 when trying to download the archive results, due to differences made in the SigMFFile class.

Official SigMF does support multiple recordings in an archive, by making them part of a SigMF collection. See here for more details.

[aromanielloNTIA]

Despite SigMF collections being present in the SigMF specification, it seems like they are not implemented as part of the official Python package. The best course of action here is probably to fork gnuradio/SigMF v1.0.0, add support for collections, and open a PR on gnuradio/SigMF to merge the changes.