Use shared_ptr for managing the lifetime of OGNumeric objects

Summary
-------

In summary, we wrap `OGNumeric` pointers inside a `shared_ptr` so
that we don't have to explicitly manage their deletion. This makes
it a lot easier to clean up during exceptions (and in general).

The form of DOGMA code is now changed to use typedef'd shared
pointers and factory methods. For example, where we had:

```C++
const OGNumeric* my_num = new OGRealScalar(1);
```

before, we now have:

```C++
OGNumeric::Ptr my_num = OGRealScalar::create(1);
```

There is a `::Ptr` type for every OGNumeric subclass. One could
similarly have declared `my_num` as:

```C++
OGRealScalar::Ptr my_num;
```

Instances of these types can generally be passed around and used
in a similar manner to that in which a raw pointer would be used.

The factory methods are used to instantiate new objects. The
constructors have been made private, in order to prevent the use
of "naked" new and delete calls, which would defeat the purpose of
managing objects with `shared_ptr` (and would also have some other
implementation difficulties).

PtrVectors
----------

Since the `PtrVector` type was used to some extent for managing
the deletion of its contents, it is no longer required.
`RegContainer` and `ArgContainer` are now an `std::vector` of
`OGNumeric::Ptr` objects. As it is no longer required, `PtrVector`
is removed.

Dispatch to terminals
---------------------

The `Visitor` implementation of dispatch was a little tricky to
keep working during the conversion of the code to use
`shared_ptr`. In order to simplify it, the visitors for
dispatching to Java arrays of arrays were replaced by two other
classes, `Real16AoA` and `Complex16AoA` that dispatch using the
`OGNumeric` type identification instead of the visitor pattern.
This is a much simpler dispatch mechanism.

The dispatch mechanism that materialises to `OGTerminal`
instances is still in existence. However, it could be replaced
with a class similar to `Real16AoA`. Once this is done, I believe
that there would be no use for the visitor mechanism, since it
provides less flexible dispatch than using the `OGNumeric` type
identification, and usually requires a whole lot more code.

Memory usage
------------

Running the fuzzer for about an hour grew the memory usage up to
736MB resident, which remained fairly stable for the duration of
the run - a small increase of < 1MB per minute. The growth up
to 736MB may be largely accounted for by growing the tree cache.
The subsequent growth requires further investigation to quantify.

Note that I do not believe this proves that we are leak free -
however, it does provide a good indication that we are not leaking
horrendously.

Further details
---------------

Further details of changes are in the commit logs - I have avoided
repeating them here in order to save having to read the same
changes twice.

Test coverage
-------------

Java: 79%
build/src/jshim: 0.8% (unchanged)
build/src/librdag: 16.4% (up 0.3%)
src/jshim: 54.5% (down 3% due to shortness of
Real16AoA/Complex16AoA vs. the old DispatchToReal16ArrayOfArrays)
src/librdag: 91.4% (down 0.4%, due to removal of containers, and
shortening of entrypt)
src/librdag/runners: 95.7% (unchanged)