Feature Request: Implement features that allow for an easier make/EA setup (à la CHAX)

[StanHash]

Here's the Making ColorzCore compatible with the CHAX makefile big thing list.

• Core shouldn't need the current directory to be EA's (it should be able to locate the stdlib/raws by looking at where the exe is)
• Core should support makefile dependency generation, through supporting the following command line options:
  • -M switches Core from assembling to just preprocessing, while monitoring includes and incbin for Make dependencies
  • -MM does as the above, ignoring files included from the EA directory (aka the stdlib)
  • -MD has Core both assemble and generate Make dependencies
  • -MMD combines -MM and -MD
  • -MF:<file>/-MF <file> sets the output file for makefile dependency generation (default is whatever)
  • -MT:<name>/-MT <name> adds a Make target
  • -MP adds a blank rule for each included file
  • -MG makes Core ignore includes/incbins for non-existant files (they're still added as Make dependencies)

Those options follow names and behavior of the pea ones, which generally follow names and behavior of the gcc/cpp ones.

The dependency output format is as follows:

<output ROM> [<extra target>...]: <input event> [<included>...]

# if -MP
<included>:;
...

File paths are relative to the calling working directory (or make it configurable?). Paths should probably be normalized to use unix-style dir separators (my version of Core doesn't do that which broke Windows builds of CHAX, oops)

Other less crucial stuff:

• 11.1 stuff (-symOutput, and that's it I think, as a = expr is on the way)
• Core should return non-zero on failure
• -input <file> instead of -input:<file>
• -quiet

For reference, this is what CHAX uses (simplified):

HACK.gba: Main.event Main.d FE8U.gba
	@cp -f FE8U.gba HACK.gba
	@EA/Core A FE8 -output HACK.gba -input Main.event || (rm HACK.gba && false)

Main.d: Main.event
	@EA/Core A FE8 -output HACK.gba -input Main.event -quiet -MM -MG -MT Main.d -MF Main.d

[Crazycolorz5]

OK so I was typing a comment and then realized halfway why it was flawed but it still has merits and I'd like to keep around why it's flawed because that's important.

I think I'd like to rewrite the way AST simplification is done in ColorzCore prior to tackling this, so that this could just be part of a chain on handling the AST. 

Currently, the AST is generated semi-lazily and is folded down (e.g. expressions are evaluated, directives are executed) as parsing occurs. The advantage of this is that macros are expanded at parse time which allows one to define macros on the token level.

Since macros are on the token, there's no way to separate analysis of preprocessor directives from parse time -- after all, if I have a macro instead of a RAW, I don't want that to parse error -- yet the expansion of the macro should be parsed.
Thus while the idea I have above has merit, for the purposes of analyzing preprocessor directives (include tools) specifically, it's not a good solution and instead I just gotta do it the hard way (adding a flag to disable assembly and writing a tracker directly into the preprocessor set to output with the flag).