change name of "recordings.msgpack.zst" to "manifest.onda"

[jrevels]

advantages:

• the onda extension on the path itself is no longer required, so a file with onda somewhere in the name is a more discoverable indicator that it has something to do with the Onda format
• less likely to be misinterpreted than recordings; the term recordings may mislead someone into thinking that there is actual sample data is lurking in there
• allows us to pick any actual file format we want moving forward without needing to worry about switching extensions
• allows us to start sensibly referring to this file as the Onda manifest, which is a bit more self-descriptive/intuitively correct than "the recordings file".
• if allow sample data and non-Onda-specified metadata artifacts to be addressed by URI rather than relative location #22 is implemented, the structure of "an Onda dataset" becomes way less tied to directory structure. At that point, we could loosen the manifest moniker to allow datasets to really by represented by the manifests themselves, so that e.g. I could send you a small bob.onda file that is a full description of the Bob dataset (whose sample data can be in an arbitrary mix of S3 buckets, for example), and an alice.onda that is a full description of the Alice dataset.
• when people use the phrase "Onda file" (which seems to be an easy mistake to make folks make) it'll actually mean something lol

disadvantages:

• Oh boy, the internal churn at Beacon will be quite the roller coaster. The deprecation path is technically easy, but I wouldn't be surprised if folks have hardcoded references to this file in a lot of places...

[jrevels]

This plan will probably have to change a bit as we figure out #25 but would be good to settle on something that jives well with the proposals there + the advantages listed in the OP

[jrevels]

This is obsoleted by #22 + #25