Use int4 and size_t where appropriate

This PR replaces the `int` type with either `size_t` or `int4` in most cases. `int4` is an `int32_t`. 

Generally, `size_t` is used for anything that is the size of an array or count of elements. Every other integer is an `int4`. The exceptions to this are:

* Lapack is fortran and is therefore using signed `int` types - anything that touches Lapack uses an `int4` for sizes instead of `size_t`.
* The JVM typedefs `jint` to be `int` on Unix-like platforms and `long int` on Windows. It is therefore necessary to keep `jint` in some places.
* Some library functions (e.g. `abi::__cxa_demangle`) expect a pointer to an `int` to return their status in, so we use `int` for them.

Supporting these changes also involves:

* `getIntFromVoidJMethod` has been replaced with `getSizeTFromVoidJMethod`. This checks that the value it gets from Java is non-negative and casts it to a `size_t`.
* The checks for negative sizes of things in the terminals were removed, since negative sizes are no longer possible with `size_t`. Values coming in from Java are still check for non-negativity, because  `getSizeTFromVoidJMethod` checks them.
* Most of the runner implementations get the number of rows and columns from terminals, which are of type `size_t`. However, because they are passed to Lapack, `int4` types are used to hold the values that are passed to Lapack.

This PR also includes the removal of `PrintTreeVisitor`, which was dead code.

Coverage:

Java: unchanged.
Native: unchanged, except for:
src/jshim: 54.3%, up from 54.1%
src/librdag: 94.8%, up from 91% (due to deletion of PrintTreeVisitor)

Confirmed.