[Mat-462] Add checking capability for inputs to LAPACK 

This PR is purely to add in some code/idea stubs because I don't want to go any further with it before we decide it's sensible given the number of call sites and bits of logic that will need adjusting due to the size of the LAPACK namespace.

The intent is:
* To add a template parameter to LAPACK namespace routines that are susceptible to getting stuck (xgesvd) or just producing nonsense on the presence of non-finite data. The template parameter is added to such routines to specify what is to be checked for in the input data prior to the call the LAPACK. At the minute `nothing` and `isfinite` are implemented. The decision to add the option as a template parameter opposed to the method prototype is so that the prototypes remain LAPACK like, also to avoid clumsy branching on testing types in the LAPACK call staging implementation. This also means that in routines where many LAPACK calls are made, necessary checks can be made prior to LAPACK calls which can then proceed without further checking.
* The LAPACK calls are all template functions so the necessary partial template specialisation is performed via buffering the call site through a specialisation struct.
* Adds two new exceptions that extend `rdag_error`, these are `rdag_recoverable_error` (error present but is recoverable) and `rdag_unrecoverable_error` (error present and cannot recover). These are added in part to circumvent the need to check many LAPACK routines' `info` variable status, and also in part to just make the exception hierarchy more sensible. Should this seem sufficient I'll mirror this on the Java side.
* Fixes up a load of runner code to use smart pointer based memory management, I did this whilst adjusting the LAPACK call sites.
 
Coverage:
Java: 82% (no change)
build/src/jshim 0.8% (no change)
build/src/librdag 40.8% (no change)
src/jshim 53.1% (no change)
src/librdag 85.9% (up 0.2%)
src/librdag/runners 95.8% (up 1%).
Would it be worth checking with quiet NaNs as well? I seem to recall that things like `1/0` will produce quiet NaNs, and we'll still want to be able to detect these.