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

  noosphere/rust/noosphere-core/src/data/headers/version.rs

  Lines 4 to 10 in b4b803e

  	/// The Noosphere protocol version
  	pub enum Version {
  	#[allow(missing_docs)]
  	V0,
  	/// All others
  	Unknown(String),
  	}

• The Noosphere Gateway REST API version

  noosphere/rust/noosphere-core/src/api/v0alpha1/route.rs

  Lines 5 to 6 in b4b803e

  	/// The version of the API represented by this module
  	pub const API_VERSION: &str = "v0alpha1";

• 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.