Allow nesting of collections and archives in collections

[jacobagilbert]

Currently SigMF Collections define the sigmf recordings contained in the collection by specifying the basename to the SigMF Recording, which necessarily is the same for both sigmf-data and sigmf-meta files in the Recording.

This is limiting in that one cannot specify Archives (of Collections or Recordings) or Collections as members of SigMF Collections, which has a variety of valid use cases (e.g.: #271).

This issue seeks to gain consensus around the idea of redefining SigMF Collections such that they can include [sub]Collections and/or archives.

[jacobagilbert]

There are a few possible ways I can think to accomplish this, and none of them are especially nice:

1. Add additional fields to the core:streams object. In addition to name we could add collection and archive. This is somewhat annoying since including more than one of these immediately becomes ambiguous and we have tried to avoid situations where "only one of the following fields can be defined".
2. Update the definition for name so it can be either a .sigmf-meta file name (overload behavior of base-name but require the full filename + extension), or a .sigmf-collection file name (and the hash would be over the collection metadata, which would in turn cover sub-collection recordings/collections hashes ensuring validity of the recursive integrity check), or a .sigmf archive. Archives are a little more complicated since its not clear what exactly should be hashed (there can be more than one metafile inside); we could simply hash the entire tar archive and deal w/ the associated complications of that. Fallback behavior (no .sigmf* extension) would indicate a Recording base name.
3. Do 2. above but deprecate name and use a new field for this.