Resource System Rewrite

[JessyDL]

Investigate an alternative approach, and then wholesale replace the existing resource loading system.

The alternative will have these constraints and goals:

• [x] support async loading
• [x] protect disk based assets (i.e. fresh copy should always be possible or immutable authoritive source)*
• [x] complex interaction (such as waiting for a GPU based event to signal) before the resource is available
• [x] support both reference tracking, as well as manual tracked modes (not needed to be mixed support)
• [x] safe resource destruction (i.e. resources are protected as long as they are in use)
• [x] support both shared and weak handles
• [ ] alias handles, we should be able to contain all graphics API related resources in a single handle, which forwards into the actual active handle. Support for multiple to be active is unnecesairy. Support for mixed operations is unnecesairy as well (i.e. we can pre-assume the active index)
• [x] internally protected from race conditions from scheduled operations (but not externally, i.e. all public methods make no threading guarantees)
• [x] ability to forward arbitrary arguments to the to-be-constructed type.
• [ ] all points need to have unit tests verifying these constraints and goals

^{* immutable authoritive source seems to be impossible without large efforts in architecture as when f.e. a buffer is loaded we obviously need to be able to write to it if it's used for those purposes.}

Notes:

protect disk based assets:

The current approach selects the "last loaded" to be the authoritive source of what is the disk based assets (for the find method), but allows load to be called N times and get a fresh version as if just loaded from disk

complex interaction:

As the system has been implemented using coroutines, you can simply use co_await in the construct method and await for you relevant signal to fire, or to switch to other threads.

reference tracked/manual resource management:

All resources are always tracked by default. This isn't toggleable for now (this is to satisfy the safe resource destruction requirement). However, you can control when resources get destroyed if it's safe to do so (i.e. the last references are held by the cache, and the caller). The try_destroy method will verify if it's safe, and will destroy the resource within the given scope.

Alternatively, the unsafe_destroy will forcibly destroy the resource. This functionality is hidden behind the RESOURCE_ALLOW_UNSAFE define.

consider renaming construct to co_construct /s

[JessyDL]

Task will be put on hold, and delayed till clear indicator when clang supports coroutines fully.