Re-organize `bevy_reflect`'s exports to de-clutter the crate root

[LikeLakers2]

Hello all! I'm making this issue per the suggestion of @MrGVSV and @\alice-i-cecile, after some discussion was had in #reflection-dev on the Bevy Discord.

The crate root of bevy_reflect is cluttered with items, which can leave the user wondering where to start with the crate.

The solution that was figured out in the Discord: Reorganize our exports - more specifically, the exports for items like Array, List, DynamicStruct, MapInfo, and so on. For example, DynamicArray's export could be in a crate::array module.

The exact way in which we reorganize the crate's exports is undecided - feel free to suggest an export layout. However, I'd like to suggest a few export layouts that came out of the discussion in Discord:

Organization Method 1

• Amalgam module

This would group all the different types (Array, List, Struct, etc.) into one module.

This would provide an experience similar to what we already have (all the different types in one module), but would de-clutter the root.

However, we would need to figure out a name for this amalgam module.

The resulting export layout would look something like this:

crate root
├── kinds
│   ├── Array
│   ├── ArrayInfo
│   ├── DynamicArray
│   ├── List
│   ├── ListInfo
│   ├── DynamicList
│   ├── Struct
│   ├── StructInfo
│   ├── DynamicStruct
│   └── ...
├── PartialReflect
└── Reflect

Organization Method 2

• Each type gets its own module, placed in the root

This would give each type of item (Array, List, Struct, etc.) its own module at the root of the crate.

This would have the benefit of being mostly compatible with our existing file structure, while significantly reducing the amount of items at the crate root.

The resulting export layout would look something like this:

crate root
├── array
│   ├── Array
│   ├── ArrayInfo
│   └── DynamicArray
├── list
│   ├── List
│   ├── ListInfo
│   └── DynamicList
├── structs
│   ├── Struct
│   ├── StructInfo
│   └── DynamicStruct
├── etc.
├── PartialReflect
└── Reflect

Organization Method 3

• Each type gets its own module, placed in an amalgam module

This is effectively a combination of methods 1 and 2.

Again, we would need to figure out a name for this amalgam module.

Additionally, if we go with Method 2 initially, we could later move to this method without much effort - once we figure out a name for the amalgam module.

The resulting export layout would look something like this:

crate root
├── kinds
│   ├── array
│   │   ├── Array
│   │   ├── ArrayInfo
│   │   └── DynamicArray
│   ├── list
│   │   ├── List
│   │   ├── ListInfo
│   │   └── DynamicList
│   ├── structs
│   │   ├── Struct
│   │   ├── StructInfo
│   │   └── DynamicStruct
│   └── ...
├── PartialReflect
└── Reflect

[alice-i-cecile]

@MrGVSV I'll defer to you on how you'd like this organized. I would personally appreciate reducing the number of root-level exports: I think it's much harder to understand, and hampers our ability to write good module-level docs.

[MrGVSV]

Thinking about it some more I think Option 2 is the best. It's simple, easy to type, and easy to discover.

I think it should be worth noting that I also believe we need to clean up the other exports and selectively put them into the bevy_reflect prelude (the prelude itself could probably use a once-over too).

[LikeLakers2]

Unless someone else is already doing it, I'd be willing to try to implement option 2 later when I'm free.

I don't know if I'll end up fully cleaning up the root as @MrGVSV wants, but I'd at least get part of it done.