BLUE CPU Software Emulator

	Software emulator of BLUE CPU described in the Caxton C. Foster's
Computer Architecture (1970) book.

	Based on the code from
https://gecko05.github.io/2022/10/22/first-emulator-part1.html.

	If you want to use this emulator yourself - take a look at the ./tests/test.c
file: usage example is in the test_program function. Kinda works so you can use
small programs on this. The only thing is DO NOT FORGET ABOUT OVERFLOWS. I did
a mistake in the test and thought that it was a bug. Wild stuff!

	Don't forget to take a look at NB comments: `grep -rn "// NB: "`
if something fails unexpectedly. You can find some info in them.

Things implemented:
- CPU STRUCTure
- CPU cycle
- Every opcode besides INP and OUT
- Does not uses standart library (am I a cool guy?)
- Most of the opcodes tested in the ./tests/tests.c

Left to implement/do:
- INP, OUT commands (reason below)
- Devices interface to communicate with CPU
- Some kind of way to interact with the CPU (explained in the note below)

?License: First you credit me: `Code taken from this guy -> github.com/msun-dev`,
then you do whatever you want except for removing that credit line.

How to contribute: "Do You really want to do it?". But on the serious note: file
an issue or something, we can discuss *what's up* in there.

Commit description logic (or how do you even call this?):
	Commits (latest) have 2 parts defined:
	1 - Title: 3 words about what commit accomplishes
	2 - 5 points about changes (removed if empty):
	- Added: Something added to a header files
	- Implemented: Something implemented in the implementation files
	- Fixed: Used to describe fixed bugs and other strange stuff
	- Updated: Tells about small parts that were changed
	- Removed: Something that was removed. FOREVER! (or temporarily)

	All changes to a file written this way:
		(ex: Added foo() in a and Removed bar() in a and fixed barf() bug in b)
		```
		Insane Commit Title
		Added:
		- a: added foo()
		Removed:
		- a: removed bar()
		Fixed:
		- b: fixed bug in barf() (most retarded explanation goes here)
		```

Note (since too lazy to make a website):
	Really wanted to make my own CPU emulator before diving into something more
complicated (CHIP-8, GB, i8080 (and the soviet counterpart), etc.).
That article mentioned in the beginning was quite nice to start that journey
(even tho it's one and only part). There were some mistakes and things
I didn't like here and there so fixed them aswell.

	Also it's an attempt to create a standalone library, albiet unsuccessful.
Like as I read somewhere I can use custom allocators for cpuInit function.
I think it's not hard to do but i'll not do it for now. UPD: Done and done.
wasn't that hard but don't know yet if all things implemented will not explode
one day.
	It sucks that if you define functions in the header you can't change
their visibility using `static` afterwards. I think I just missing something.
Will revisit this idea after I get some more experience. Wanted to make some
kind of User API and hide inner functions (wanna see them in the header
uncommented and make compiler to keep track if something implemented or not)
but failed miserably.

	And I kinda succeeded in the project structure. Kinda okayish. (Even tho it's
just a 3 folder and 2 files).
	And this way of writing README is waaaaaay better than that shit github has.
Take that! you shitass platform, I'll not use your shit formatting you provide
in the markdown files!

	Also as LE FUNNE I want to make it so you can run around this CPU in the 3D
world. Let's say all of that implemented in the Raylib where you can in the real
time see the data in the CPU and maybe jump right on top of it to corrupt data.
Maybe some time in the future as the separate project... And also this,
and also th...

	Speaking of std: its nice to make a draft of an app (saves a lot of time)
and then as time goes on swap parts of std to your own implementation.

See You soon!