Revisit BRP naming strategy for consistency with Rust types

> It is a bit weird that this is deviating from componentInfo's field names for some fields and matching for others.

> The issue I faced was the unserializability of ComponentInfo and its fields.
> I was torn between:
>
> Wanting to mirror data from ComponentInfo 1 to 1.
> Slightly adapting the fields to a similar format.
> I decided to rename fields/structs to reflect this "almost the same but not quite", hence the "Type into Kind". And then I forgot this when I named the ComponentMetadata::storageType field, which should probably be ComponentInfo::storageKind if follow my logic. Or maybe not since StorageKind is actually equal to StorageType ...
>
> But do you have suggestions on how to better handle this? Should StorageKind be changed into some sort of new type tuple? What are best practices for serializing an unserializable type?

> I don't think this needs to be solved in this PR. My understanding is that the whole rest of the BRP API surface does the same thing so it would be a big refactor to change that. I just wanted to call out for documentation purposes that this is happening.

Originally discussed by @ChristopherBiscardi and @splo in https://github.com/bevyengine/bevy/pull/23102#pullrequestreview-3870715097_

Start with the naming discussion linked from PR #23102 and compare the BRP names with the referenced ComponentInfo fields and Rust types. Determine whether the API should mirror ComponentInfo, adapt its names, or introduce distinct serialized types; done means a documented, consistent naming strategy and an agreed scope for any refactor.

Written by the indexing model from the issue text.