Guard PDRange constructors against invalid ranges

[pingpingy1]

This PR intends to provide suitable guards against invalid arguments to the PDRange constructors.

The first case is when the COSArray range parameter is given the null value.
Here, the null value is directly saved to the rangeArray variable, and cannot be set to a non-null value using any other public method.
Hence, I argue that this case should be guarded against in the constructor, either by throwing an exception (for example, using the Objects.requireNonNull method) or by setting the range to a default range (as implemented in my commit using 0..1).

The second case is when the index parameter leads to invalid indices for the range's minimum and maximum values.
Again, the provided index's value is directly saved to the startingIndex variable, and cannot by changed via any public method.
Moreover, no public method could lengthen the rangeArray.
The methods setMin and setMax do not check the validity of the indices 2*startingIndex and 2*startingIndex+1, which could throw exceptions down the line.
Thus, I argue that this case also should be handled here, either by throwing an exception (as implemented in my commit using IllegalArgumentException) or by using a default index (such as 0).

[pingpingy1]

Oops, didn't realize I hadn't written tests for the new guards. My bad.

[THausherr]

I'm not sure if this is helpful, because bad parameters may not just come from users, but from bad PDFs (although unlikely). A user constructing PDRange with a null COSArray will just get an NPE and IMHO this is fine. What remains is the case where a PDF has an array that is too short. It's possible that we do already catch this, for example getEncodeForParameter does so. Such PDFs should not fail with an IllegalArgumentException because this is an unchecked exception.