Establish versioning semantics at various layers of the protocol

[cdata]

In #624 we introduced a version bump in part of the Noosphere Gateway REST API, which prompted some discussion about versioning semantics. We currently have a few "layers" of versions in our system, including:

• The Noosphere "protocol" version https://github.com/subconsciousnetwork/noosphere/blob/b4b803e3f4269980577cca700dab09c4cd13d01b/rust/noosphere-core/src/data/headers/version.rs#L4-L10
• The Noosphere Gateway REST API version https://github.com/subconsciousnetwork/noosphere/blob/b4b803e3f4269980577cca700dab09c4cd13d01b/rust/noosphere-core/src/api/v0alpha1/route.rs#L5-L6
• Noosphere Rust crate versions (each versioned independently)
• Noosphere embedding package versions
  • Swift package (version currently lock step with Rust noosphere crate)
  • NPM package (versioned independently)
• Possibly others

This issue is being opened to prompt us to discuss / define the semantics of these versions and their relationships to each other.

[justinabrahms]

the protocol and gateway APIs should, imo, move independently of the underlying rust code. I agree that it makes sense to keep embeddings closely related w/ their rust implementations, because you're more tied to the revealed functionality.