Eliminate NonSend resources by making World optionally !Send using generics

[alice-i-cecile]

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

NonSend resources are confusing (they don't impl Resource!), badly named (#13481), require API duplication and hamper us when implementing valuable new ECS features like #17485.

That said, not everything we might want to stick in and access from the ECS is threadsafe! Audio, window handles, scripting language integrations and more are all inherently !Send. Simply removing them is not an option.
Ultimately, the problem is that our model here is muddy, hampering our ability to teach, reason about and safely improve these areas of code.

Simultaneously, users have requested support for !Send components, particularly for use with web or scripting languages.

What solution would you like?

As discussed in the resources as entities Discord thread (and proposed by @bushrat011899, we should support !Send Worlds.

We already have a powerful, type-erased storage. We should take advantage of it, expanding the possibilities for users while clarifying the semantics and ensuring that our objects are either clearly Send or !Send.

PR 0: Send-generic World

To do this, we can add a generic parameter to World, which conditionally holds a PhantomData which makes it !Send. See this playground link for a proof of concept. To make that nice, we probably want a sealed trait, meaningful names and an associated constant on that trait that you can check at runtime. Steal from the immutable components design.

PR 1: Move Send+Sync trait bounds

Currently, the Resource and Component traits require their types to be both Send and Sync. In this brave new world, this is no longer required! Nonsend resources can be actual resources! We should remove those bounds, and add them to the dangerous methods (hi parallel executor + parallel query iteration) which actually require them.

PR 2: App stores a !Send world

As laid out by @maniwani, make all apps regardless of platform would come with a world (thread-safe world) and a centralized thread-local storage (thread-local world).

PR 3: Thread-safe worlds can access thread-local data

Allow systems in the normal world to access non-send data, stored in the thread-local storage. Normal systems never directly touch non-send data (except on web). The mechanism will look something like this.

fn system(mut thread: ThreadLocal) {
    thread.run(|tls| {
        let x = tls.resource::<X>();
        /* ... */
    });
}

The thread-local world should live to service requests from the thread-safe (main) world, although users with particularly unusual needs could operate with only a thread-local world or add and run systems to it.

PR 4: Migrate internals to new system

Move all of Bevy's NonSend usages to the new strategy, and make sure everything works.

PR 5: yeet NonSend

Remove all of the internal now-redundant machinery that is currently used to implement !Send resources.

Future work

• better multiworld APIs
• multiple thread-local worlds by default? Audio might want a dedicated storage and thread for performance
• resources-as-entities

What alternative(s) have you considered?

See the following previous attempts at this flavor of work:

• Do not incorrectly impl Send for World  #3519
• Move Non Send Resources into thread locals #5135
• Take non-Send resources out of World #9122

This solution is powerful, elegant and minimizes API duplication.

Using a const boolean would work, as seen in this playground proof of concept, but results in uglier and less explicit APIs.

Once const-adts is stabilized, moving to a custom enum will give us a simpler, cleaner solution without sacrificing clarity.