[Mat-426] Wiring in OG-Izy and using it in working implementations.

This PR makes a start on all the plumbing, testing and wiring required for the OG-Izy style vector functions. Unfortunately, this does mean it includes the addition of quite a bit of code that is added all at once due to the overhead caused by doing such a task in a fragmented manner. Similarly with the code generators, they are work in progress, a number of things had to change simultaneously and the code below contains the most basic of use cases and some sample implementations. I'm of the view that most will need refactoring, however I wanted to get this code in as it's getting quite large and it is unknown how much more effort is need to work out exactly how to make the various combinations of tooling do the thing I want!

This PR:
* Adds in the template headers for `OG-Izy` functions and most of the partial template specialisation required to wire them up in a type invariant manner.
* Adds in the generated code for the "safe" (by the Sethi-Ullman discussion definition) nodes, i.e. ones that don't change mathematical domain when run.
* Adds in autogenerated tests for the above, these are provided by m-code and are committed to the source as having a dependency on an interpreter of m-code at compile time is undesirable. At the minute only the C++ side testing is generated. The java side will be generated as part of the next refactor.
* Adds in jinja2 templating capability to the node generator. This was to deal with needing flow control in templates as some OG-Izy functions are order invariant e.g. `addx()` has no `xadd()` counterpart as it would be pointless. However e.g. `subx()` has a `xsub()` counterpart as clearly necessary. As a result of this the function prototypes are different and so some flow control is needed at generation time to perform introspection on the functions provided and then order the arguments at the call site correctly.
* Adds in the common infix operator nodes and adds hand written tests for them from DOGMA and java.
* Adds in the capability of specifying tolerances in the `CheckNode()` classes.

As noted in offline discussion, the tolerances in the autogenerated code for the OG-Izy bound functions are somewhat high. This is due to 32bit windows defaulting to mscrt maths library functions which differ in result to those provided by 64bit/POSIX. A workaround is slated and will be added in due course.

Coverage:
Java: 82% (up 5%)
build/src/jshim 0.8% (no change)
build/src/librdag 40.8% (up 23.7%)
src/jshim 53.1% (no change)
src/librdag 85.7% (down 8.5%, this is partly due to the really simple dispatch stubs not being covered for the autogenerated stuff, I'll look into adding this in as part of the template based generation. Also it's partly due to the addition of `izy.cc` which is entirely added and implemented, but not yet entirely used as noted above.)
src/librdag/runners 94.8% (no change).