Add memory and data-related implementations for handling game data.

Use consistent integer types for mocks.

Properly mock video function dependencies.

Correctly dereference pointers.

Update input tests.

Declare memory before processing.

Declare variables early on.

Use short names for int types.

Provide default states for input and output.

Allow MIDI input to be filtered through MIDI channels.

Use higher bits of first message byte to get notes from all channels.

Restrict Yes/No actions in same 2-octave span.

The file has been updated upon introducing MIDI controller input
support.

The game now uses MIDI support for alternative input methods.

Put I/O values to their respective structs.

Isolate input items into their own directory.

Ensure joystick direction enum names are consistent.

Ensure each initialization method is in its own source.

Ensure correct arguments are passed.

Determine config path only once.

Add spine-runtimes to dependencies

Add geometry methods for point, vector, and rectangle.

Ensure one type of test can only be handled at a time.

Implement tests for joystick axis, hat, and button events.

Order files from order of includes.

Add third-party mocks, specify mock files.

/? Do we need first-party mocks in their own files, or can we provide a
mock flag in the implementation files already?

Make device handling opt-in.

Use types from header file.

Use call count type to contextualize call counts.

Use macros for syntactic sugar.

Include mocks and stubs implementation in config unit tests.

Use #define instead of const for constants.

Use bdd-for-c for unit tests.

Honor the FPS cap with updating video. Now the update occurs after
processing all the input actions.

Implement event handling for gamepads and joysticks.

In addition, the events are ordered according to SDL compatibility.

Extract config-related code to their own source files.

Ensure that initial loading of the config saves the values back to the
config file, in order to account for fallback values.

We use minIni to parse ini files instead of implementing our own. This
is useful for config modifiable by the user, such as controls.

However, we haven't implemented a fault-tolerant config that writes to
the config when the existing file is corrupted or non-existent. We will
have to define a "save" as soon as we have all values defined for our
in-memory config, regardless if we have retrieved the values
successfully or provided default hardcoded values.

Since we use an external dependency to manage our configs, the CMake
config must be modified and the source files included in the build. How
do we organize the dependencies from other Git repositories moving forward?

Make CMake load dependencies relative to project directory.