* The instruction decoding was based on the handy table in ps2tek [1]
while the instructions themselves were written based on the document
added.

* The implementation makes heavy use of bitfields and unions in C++ to
make accessing different bits/sections of registers easier and more
intuitive. You may also notice the frequent casting (uint32_t)(int16_t)
which might seem useless but is there to force the compiler to generate
instructions to sign extend the offsets.

[1] https://psi-rockin.github.io/ps2tek/#eeinstructiondecoding

* Now that the BIOS is loaded we can start executing it!
The starting address the EE uses is 0xbfc00000 which maps
to KUSEG1. Since all KUSEG regions except KUSEG2 are mirrors
of each other we only need to translate the address to the
KUSEG appropriate.

* The functional differences between KUSEG0/1 are minimal and
very niche so I won't bother emulating them now. Address wise
we can notice that the only difference between addresses is the
most significant half byte. By using that byte as an index in
a mask table we can define an appropriate mask for each KUSEG
address. Idea taken from a very handy PSX document I discovered
last year [1]

[1] https://svkt.org/~simias/guide.pdf (43)

* The ps2tek documentation states the memory map clearly [1].
It seems to have a similar architecture with the PSX, where
the main memory map (KUSEG0) is mirrored in multiple regions
(KUSEG1/KUSEG2) with different access patterns for each region.
For now we don't have to emulate all of them, just the main
memory map.

* Allocate the entire 512MB memory into an array and make a convenient
struct to abstract memory range operations.

[1] https://psi-rockin.github.io/ps2tek/#memorymap

* This commit adds a most basic CPU class that acts as a template
which we will slowly build.

* The architecture is pretty simple; the ComponentManager will create all
the seperate components (EE, VP, IOP, GS etc) as unique_ptr's since
it owns them and only it has access to them. All the other components
must pass through the manager to read/write data to memory.
To achieve this they are given a pointer to the ComponentManger in their constructor.

* For now the CPU directly accesses the bios which shouldn't
happen but will be fixed eventually when I implement generic
read/writes. The goal is to start implementing the CPU as fast as
possible in order to get to the GPU/VPU's and display something!

* This is the beginning of a surely arduous journey of semi-correctly emulating
the PS2 the flagship console from Sony in 2001. The console was chosen
for it's impressive performance at the time, relatively simple MIPS architecture
compared to the PowerPC (Gamecube) and x86 (Xbox) competitors at the time, and because
I own one since I wouldn't want to be caught doing piracy on an open source
competition...

The PS2 also has a myriad of resources available including comprehensive CPU documentation
for it's MIPS ISA which will be used in the development of this emulator. Any sources that I use, will be referenced
in the coresponding commits for the judges to look at. For development hardware documentation and info from real emulators will be used
(I'll try to avoid using code from other projects as much as possible though).
I've also done a PS1 emulator in the past so the minor similarities in architecture
will help speed this process up a little.

For now this is just a window with glfw and a ready opengl context.
I hope it will be able to boot the PS2 soon enough though...