Enables the standard GH analysis action for LLRI.

The build file generates vcxproj files using CMake because the analysis auto build workflow doesn't currently accept CMake on Windows.

The analysis currently only runs on Windows because both llri-dx and llri-vk are built on Windows, which is sufficient because the code between platforms doesn't change.

Is your feature request related to a problem? Please describe. Copyright is described on a per-file basis, with a starting and current year - A GitHub action should keep the current year updated by running on a yearly basis.

Describe the solution you'd like Integrate https://github.com/FantasticFiasco/action-update-license-year into the repo's actions, configured in such a way that it checks every source file for the copyright notice.

Simplify applications that don't require elaborate adapter selection by allowing device creation without an adapter, in such a way that createDevice() will simply select the default adapter (enumerateAdapters()[0]).

This PR reorganizes the project structure to provide a more out-of-the-box usable library. The PR changes the project structure to be as follows:

root/
	include/		- Header files
	lib/			- Lib files
	deps/			- Dependencies (must be included & linked against)
	legion/			- Source code
	applications/		- Executables (sandbox, unit tests, samples)
		deps/		- Common dependencies for (sample) applications. Not required for LLRI
		samples/	- Example API usage
	binaries/		- Project build files (local)

The PR also includes two samples: 000_hello_llri and 001_validation which introduce the basic core concepts of LLRI. The vast majority of files changed are moved dependencies but the project setup and the samples should be reviewed.

This PR introduces the validation message callback. This callback can be used to receive messages from both the LLRI API and the internal API (Vulkan/DirectX).

To accommodate for this, all API functions have been split into a pre-implementation function (llri_impl.hpp) where validation can be applied, and their implementation functions (impl_function()) which get implemented for each API. To prevent this feature from introducing potential performance overhead, the pre-implementation functions are inlined, and the feature introduces the LLRI_ENABLE_VALIDATION and LLRI_ENABLE_INTERNAL_API_MESSAGE_POLLING preprocessor flags that can help prevent LLRI from running unneeded checks in release builds.

Other than those two flags, the feature introduces:

1 new structure

• validation_callback_desc Which is passed into the instance_desc structure and allows the user to pass a callback function and a user data pointer. Passing a callback is optional, the API will simply not forward callback messages if no callback function is passed.

2 new enum types

• validation_callback_severity Describes the severity of the message (Verbose, Info, Warning, Error, Corruption)
• validation_callback_source Describes the source of the message (LLRI Validation or the InternalAPI)

All enum types come with matching to_string() functions for ease of debugging.

1 new function pointer

• validation_callback Is used to receive callback messages from LLRI and its internal API. It passes a severity, source, message, and optionally userdata.

This PR removes the legion shader preprocessor build in applications because the build was very bloated (taking over the vast majority of the repo's stats/info) and it'll likely need to undergo significant changes before being reintroduced

This subfeature introduces the Instance as the core structure of the LLRI API. The subfeature brings the following:

1 new handle:

• llri::Instance is responsible for the creation of all API objects in the application. It's the equivalent of VkInstance, DXGI_Factory and an OpenGL Context.

3 new structures:

• llri::InstanceExtension Describes an optional instance extension. These extensions may or may not be available depending on the available internal API, and the system's hardware and drivers.
• llri::APIValidationEXT An instance extension that enables API validation. API validation causes performance overhead but is useful in debugging scenarios.
• llri::GPUValidationEXT An instance extension that enables GPU validation. GPU validation causes significant performance overhead but can be useful when debugging shaders or synchronization issues.

1 new enum type:

• llri::InstanceExtensionType Describes the kind of instance extension. This value is used in InstanceExtension and is used internally to recognize the extension type and cast InstanceExtension::data to the correct underlying type

3 new functions:

• llri::createInstance() Creates an instance handle with the given instance description. Passed extensions are created/enabled internally.
• llri::destroyInstance() Destroys the instance and its internal extension resources. This does not include resources created through the instance, that responsibility remains up to the user.
• llri::queryInstanceExtensionSupport() Queries the support of the given extension. Returns true if the extension is supported, and false if it isn't.

Unit tests now support a cmake flag that override the adapters that the tests should run on. This enables local configurations to only run on the selected GPU(s), which will be desirable for localised runners who might not wish to give up all their system resources.

If no GPU is specified in CMake, all GPUs are selected like normal.

Updates names, links, and moves all source code from /legion/engine/ to /src/

note: the license badge doesn't work on my preview but I believe that's because I updated the repo name after I updated README.md, I assume it'll re-parse on merge

Introduce functions for each object type that enables the user to get the native pointers of underlying types. This allows users to integrate with libraries that expect native pointers. Users can then use llri::getImplementation() to cast the resulted pointers to the correct types.

in createInstance(), llri-vk uses raw strings in the unordered_set, switching to compile time hashed strings would result in a minor performance improvement

Using https://lgtm.com/projects/g/Rythe-Interactive/Legion-LLRI/logs/languages/lang:cpp you can setup code quality reports which might be neat.

also using https://app.codecov.io/gh/Rythe-Interactive/Legion-LLRI you can setup code coverage.

am planning to set it up for rythe as well once i'm done reworking the build process

There's no consistent style in which comments are written in the repository. Establish a consistent rule for comments (we could for example require standard English rules - start with a capital letter, end with a dot), and enforce the ruling throughout the codebase.