Remove `LogMsg`

[jprochazk]

Currently, all communication between SDK and Viewer is done through LogMsg:

rerun/crates/store/re_log_types/src/lib.rs

Lines 263 to 280 in 3a50bc2

	pub enum LogMsg {
	/// A new recording has begun.
	///
	/// Should usually be the first message sent.
	SetStoreInfo(SetStoreInfo),
	/// Log an entity using an [`ArrowMsg`].
	//
	// TODO(#6574): the store ID should be in the metadata here so we can remove the layer on top
	ArrowMsg(StoreId, ArrowMsg),
	/// Send after all messages in a blueprint to signal that the blueprint is complete.
	///
	/// This is so that the viewer can wait with activating the blueprint until it is
	/// fully transmitted. Showing a half-transmitted blueprint can cause confusion,
	/// and also lead to problems with view heuristics.
	BlueprintActivationCommand(BlueprintActivationCommand),
	}

With LogMsg, we're mixing a lot of different concerns into one thing. Now that we are migrating our SDK/Viewer comms to gRPC, we can do better. For example:

• An endpoint to acquire the store info for a recording ID, replacing SetStoreInfo.
• An endpoint to stream in all chunks from a recording, replacing ArrowMsg, and removing the need to pair each chunk with a store ID, because it's implicitly known by the client when opening the stream.
• An endpoint to fetch the blueprint for a recording. This wouldn't have to be streamed at all, so we wouldn't need a BlueprintActivationCommand as a "stream end" marker.

On the rrd file side, we could:

• Migrate it to only hold one recording, and put StoreInfo in the file header, removing the need for SetStoreInfo.
• Use a separate file type for blueprints, removing the need for BlueprintActivationCommand. We already do this with .rbl, but we'd need to actually enforce it.

We probably still want multi-recording (including mixed with blueprint) files, but we could wrap these into a "rerun archive" file format, and provide the tools necessary to produce these files, as we currently do with rerun rrd.