Merge labels when generated next to each other

[ghost]

When 2 labels are generated together, they are merged into one. Changed an example to have 3 nested if-statements, which otherwise would have generated:
iflabel0:
iflabel1:
iflabel2:
Which is now just
labelN:
As well as being able to merge labels regardless of whether they represent if/while/functions.
I'd like to eventually add an IF macro to allow multiple conditional statements to be included in a (X; Y; Z; ...) format to avoid further nesting

Also fixed minor formatting and most compiler warnings

[Thomas-995]

I'm confused why you added a line to strlwr.con that makes it, after checking if byte[str] is less or equal to 90, check if byte[str] is not equal to 95. It is a redundant if statement no? Also as far as the merge_labels thing goes, I like it but I wanna create an actual structure for implementing compiler optimizations instead of just throwing around optimization functions randomly.

[Thomas-995]

I don't see much of a point in implementing an ERROR comparison type, since the //ERROR comment is just somewhere I haven't implemented an exception yet, and what I want to happen there is that it just spits out an error message and then exits the compiler completely. We could make it so you can see all the tokenizer errors at once without having to fix and only then see the next one. As far as the output + "\n" stuff goes, I think I prefer if we just check if its not the first line instead of putting the output += "\n" on every if statement.

[NoneSince]

regarding exceptions my friend, no need to wait for a dedicated exceptions system to write "throw" in the code. later there can be a commit to define how to report errors, and maybe how to debug and so on. We just make the current state better, and after that we in-sha-allah make the "better state" better.

for example, in parse_construct() i locally added a try-except to quickly manage that:
try {
new_token = parse_line(code_split[i]);
}
catch (const std::exception& e) {
throw std::runtime_error("Line "+to_string(i)+" ["+code_split[i]+"] :"+e.what());
}

This is better than not reporting the existence of errors, and better than "exit(1);", because it shows the problematic line with an (not that good) error message.

About error value this PR adds, this can be a good approach (a person can live without exceptions), but I think he just wanted to remove the compilation warning, not to "return error value" and check everywhere if "an error was returned", and "act accordingly" (make the error in this function reach main() and print presentable error message).

[ghost]

I don't see much of a point in implementing an ERROR comparison type, since the //ERROR comment is just somewhere I haven't implemented an exception yet, and what I want to happen there is that it just spits out an error message and then exits the compiler completely. We could make it so you can see all the tokenizer errors at once without having to fix and only then see the next one. As far as the output + "\n" stuff goes, I think I prefer if we just check if its not the first line instead of putting the output += "\n" on every if statement.

The +\n also fixed the extra newline at the end of the file, but it's purely aesthetics so I can revert those, no problem.
Same for the error, which @NoneSince also brought up, and they had some good points.
And also, for the extra line, yeah, it's redundant. Just was the end of the night, got everything working the way I wanted, got excited and just wanted to show it worked with N items. I'll come up better conditions, or better yet, just a better test file to showcase these.
Did you have any ideas for an optimization structure? Right now, since ifs, functions, and loops are all different structures, we'd something that works with all of them at the same time. I think merging neighboring labels is an easy optimization to do at the end, and we can always replace it in the future. I just don't see an optimization that approaches this method in simplicity, as I think all other optimizations will likely require much more fancy and complex functions, or a reworking of the current data structs. I could absolutely be wrong, though.
What do you think? Do you want me to try to come up with other solutions and propose them? Or is it good enough for right now to remove the formatting and exception stuff, and keeping the current adjacent label merging?