Make `TypeRegistry` global available

## What problem does this solve or what need does it fill?

`bevy_reflect` uses `TypeRegistry` to keep track of metadata used to dynamic interact with `Reflect` types. This is also used by ser/de operations, like `bevy_scene` and any networking.

Users should keep a reference to a single `TypeRegistry` that contains all types registered and pass it around to `Scene`s, `ReflectSerializer`, `*ReflectDeserializer` and any type which needs to deal with its metadata, which is very verbose to carry around.

Also this make it hard to have custom `ReflectSerialize` and `ReflectDeserialize` implementations, since there is no `TypeRegistry` available, where in this case, users should make the `TypeRegistry` global available themselves.

Usually the `TypeRegistry` is written once, at the `App` startup, either by plugins or by any custom logic, and then read by any `bevy_reflect` operations which needs to know it's metadata.

## What solution would you like?

Add a default global available `TypeRegistry`, to be used when a single `TypeRegistry` is required (which should cover most use cases), but keep `TypeRegistry` to be instantiated and be used individually when required (something like `ReflectSerializer::with_registry`).

1. Make `TypeRegistry` global available;
2. Change `ReflectSerializer`/`*ReflectDeserializer`; to use global `TypeRegistry` by default;
3. Add an option to use a custom `TypeRegistry` on:
1. `ReflectSerializer`;
2. `*ReflectDeserializer`;

## What alternative(s) have you considered?

Let users create a global available `TypeRegistry`, to be built after app startup and use it. This will solve the problem of accessing `TypeRegistry` inside a custom `ReflectSerialize`/`ReflectDeserialize` but keeping the verbosity of carrying around the `TypeRegistry`.

## Additional context

I'll do some researches on this subject, but there are some questions which needs to be solved, mostly to know how far should we go with this enhancement:
- [ ] 1. Should we change `DynamicScene` to also use global `TypeRegistry` by default?
- [ ] 2. Should we remove the `App::register_type` in favor of a static `TypeRegistry::register_type`?
- [ ] 3. Should we remove the resource `TypeRegistry` from `App`?

Also, another questions to be answered:
- [ ] 1. There are some use cases where multiple `TypeRegistry` should be kept around?
- [ ] 2. There are some use cases where new types will be registered, after the app startup stage?