Interop support for the Configurator API and all plugins

[DynamicField]

It's currently hard to get anything — such as a window, at least — popping on your screen with the C API. This PR implements the entire Configurator API and all of its plugins. Making your dreams of a game engine usable in C a reality.

What's implemented

• NrtConfigurator: methods to add plugin providers, as well as default systems
• All variants of IPluginProvider: (Graphics, Input, ResourceManagement, Windowing)
• GraphicsProvider: barebones with only a Destroy method
• IWindowingDevice: with all methods (except TearDown), such as ProcessMessages, GetShouldClose and WindowTitle manipulation
• IInputDevice: with all methods (except Initialise and Update)
• ResourceLoader: only the ResourceRootDirectory property has been implemented

Questionnable implementations and the reasoning behind them

LifetimeExtender

The AllObjects<T> function uses a templated static variable for each type, which can maybe cause issues with multiple TUs. However, linkers should automatically choose only one static variable across multiple TUs: that behavior is called vague linkage.

NrtConfigurator

The AddXPluginProvider methods use Lifetime::Find to get a shared_ptr of a plugin provider. This method uses linear search on all shared_ptrs created by the C API. It shouldn't be an issue considering we don't spawn thousands of PluginProviders, but it's something to note.

NrtInputActionList

I choose to implement a span of NovelRT::Input::InputAction instances with a struct that mimics an actual span:

typedef struct {
    NrtInputActionHandle begin;
    NrtInputActionHandle end;
    intptr_t increment; // sizeof(InputAction)
} NrtInputActionList;

Contrary to iterators, they demand more "discipline" to be used, but they are much more efficient for performance (no allocation, no need to call an externally-linked method every time), easier to implement (it's just one struct!) and it actually makes sense for a span. The intptr_t Nrt_InputActionList_IncrementSize() method is there if you want to make it a constant. (it's also pretty cool for a JIT!)

[capnkenny]

Note: may need to squash commits upon approval

[RubyNova]

Update for this - I've gone ahead and implemented the resource loader APIs. I don't know how it affects your plugin support, but please review it.

[DynamicField]

Update for this - I did the changes and adapted the existing code to the new APIs, the only thing missing is... the tests.

[RubyNova]

If you can't test some of it that's fine, just test what you can, we need to get this moving.