Service Provider and Dependency Injection

[thelivingdiamond]

Exploring how chairloader might work by using a service provider to handle dependency injection and seeing what benefits and challenges there would be

[thelivingdiamond]

Idk if it's actually a good idea to do this, be maybe we could replace all of gCL with the service provider.

Once again, not sure what the benefit strictly is other than we can add services more easily without screwing with the environment definitions?

A change to the mod sdk to allow registering services would potentially be the main benefit, but if we already have the provider might as well switch over right?

[thelivingdiamond]

Alternatively and on second thought, separate the mod service provider from the core service provider. If mods need to register services anyways it needs to happen after the first provider is already constructed. I do think it might be beneficial architecturally to separate the web of static references into a service provider in chairloader core, but that could be a project for later.

This would let mods provide services. This is technically similar to the system we already have with connect and query interface, but maybe with a bit more complexity. Eh, I dunno

[tmp64]

I like this approach and I support replacing ChiarloaderGlobalEnv with a service provider. But mods should definitely use a separate service provider for their interfaces.

[tmp64]

Strings can be used instead of std::type_index

[thelivingdiamond]

Ok, updated the service provider implementations. Refactoring chairloader to remove gCL will be quite the task though lol

[thelivingdiamond]

Started moving things over to the service provider. I made the different ServiceEnvironments because of the different projects for core, cryrender, etc... but there may be a cleaner way to do it.

I can't think of much of a better way to handle casting the interfaces to the concrete types, ideally we wouldn't need to do that, but we may have to tweak the SP and/or the interfaces themselves to fix that.