Refactor Solver pattern to match profile configuration pattern

[SimonDarksideJ]

Overview

In reviewing the migration of the Solver framework, it has highlighted some points which don't fit in to the vNext updated patterns. namely the reduction of MonoBehaviours and the user of scriptable config to profile the configuration of components.

As I understand it (and please correct me if I'm wrong), All solvers require and depend on the Solver Handler. The Solver Handler is then primarily responsible for ensuring all the solvers attached to the object are run and maintained.

Thus, Only the SolverHandler actually needs to be a MonoBehaviour, all other solvers should simply be c# scripts using Scriptable Config profiles to attach them to the solver handler (the solver handler should also be able to have N+ number of solvers in it's configuration.

Requirements

• Solver handler to be refactored to maintain a config profile
• Solver handler needs to be able to have n+ solvers attached / configured to it
• Solvers need to be refactored, so that they can can be "attached" through configuration to a Solver handler
• Solvers independent configuration either needs generalizing (so it can be managed in the handler) or orchestrated to ensure conformity across solvers
• Ideally, the Solver handler should have a "profile" to enable attaching the same profile to multiple handlers and reduce the configuration overhead (similar to other config profiles)

[david-c-kline]

• Prefab creation loses the connection to the scriptable object
• Changes to scriptable object settings at runtime get applied to the asset without cloning
• How few customer requests around this issue.
• Is DOTS something we should move closer to?
• What is the Unity guidance for use of scriptable objects?

[Zee2]

Closing as duplicate of #10759 for upcoming Solvers+Constraints unification and refactor. See @RogPodge for more info