Fix ocassional orly_client segfault

Periodically an AST node would be deleted twice, causing a segfault.

This is resolved by changing the memory management to be unique_ptr based, and teaching bison how to properly destruct the stack of objects it has created on error. This should hopefully also mean the leaks which had been visible are largely gone (Although I have no way to verify that ATM, and more leaks may exist in the flex side).

As sort of a drive-by fix, the Bison parser is made not to use a global variable to pass around the parser. That is the first step in getting the bison-generated parser + flex generated lexer to be fully reentrant (To continue you have to eliminate Tools::Nycr::TError, which isn't worth it at the moment, since I'd have to restructure non-trivial portions of orlyc's syntax and synth layers to pass around a context into which they push errors, rather than writing them to the global list).

For just making the flex + bison chunk of the compiler generated by nycr fully reentrant, what needs to happen is we pass in a 'context' object to the parse() and lex() function (Via the `%parse-param` and `%lex-param` directives in bison), as well as making flex output a reentrant lexer `%option reentrant`). The context object needs to be where errors are logged to, as well as hold pointers to the text / data buffer we're parsing inside of (the NycrPrepStr/NycrCleanStr functions will go away entirely / just be actions the context object performs).