Allow NonSend components

[alice-i-cecile]

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

Allow data that is not Send to be stored in components, increasing API flexibility.

This is particularly useful for structs that contain a Cell or similar, allowing for interior (within-system) parallelization.

What solution would you like?

Mirror / share the NonSend resource API. Systems that have at least one NonSend component or resource access can only run on the main thread to ensure that the data does not have to be passed between threads.

Reusing NonSend for both resources and components would be the best naming scheme for this if possible.

What alternative(s) have you considered?

Store a reference to a NonSend resource maybe? Just Don't Do That.

Additional context

This will impact the Component trait (#1843), as it will not include Send + Sync trait bounds. Instead, those will be limited to using components in a parallelizable fashion.

[Ratysz]

Systems executor relies on this method (looks like it's better-documented on the main branch?) to know if it has to schedule the system on the main thread. It simply reads SystemMeta::is_send, which is set in SystemParamState::init(). Should be plug-and-play.

[james7132]

Closing this for the same reasons as #1719 and #4247. Supporting !Send resources and components has serious soundness issues with World: Send + Sync and has scheduling issues.

For more context, please see this discussion on Discord: https://discord.com/channels/691052431525675048/692572690833473578/1047997793375096852, and #6552.