Proposal: Abstract Threading support

[capnkenny]

What is the current behaviour?
At the moment, NovelRT contains a hard dependency on oneTBB, specifically for mutex support.

What is the expected behaviour/change?
I propose that we abstract any of the threading support required in NovelRT (thread, mutexes, etc).

What is the motivation / use case for changing the behavior?
At the moment, oneTBB can be a pretty big beast to compile for systems and has pretty specific rules during compilation.
As a result, it may not be desired if one wants to use backends such as SDL2, where there is threading support built in, or for mobile platforms where oneTBB may not necessarily be desired.
This is mainly for future scenarios (Web, Mobile, additional backends as they are added)

Describe alternatives you've considered:
Considered making a port of oneTBB for each addtl platform - very difficult, some incomplete versions exist already but again are incomplete.
Also considered moving only to stdlib - not completely desired as other implementations still have perf. benefits over stdlib implementations.

Are there any potential roadblocks or challenges facing this change?
This is dependent on how we utilize threading - if there's areas where we need specifics it may become difficult to abstract.
Will also require a C API - a challenge enough as it is :^)

Are there any downsides to implementing this change?
There may be some perf loss as oneTBB (previously) was considered the best balance of performance and accuracy. This should not be noticible to end users, however.

Additional context
N/A