Task: Make Capacity and EnsureCapacity() sensible to use on SubList<T>

[NightOwl888]

In the JDK:

1. There are no equivalent methods for Capacity (getter or setter) on either AbstractList<E> or ArrayList<E>.
2. ensureCapacity() exists only on ArrayList<E>, so it cannot be called on a SubList

So, we have a gap because both of these members exist on List<T>, the base class of SubList<T> but do not exist on a JDK sublist.

The logical way to address this is to use the same approach that was taken for the other SubList<T> members - that is, make them act as if the elements in the SubList<T> (along with any free space in the underlying array) are the only things that are visible from the public API.

1. Capacity (getter) - Should display a calculated value based on the sublist size + the amount of free space in the unerlying array.
2. Capacity (setter) - Assume the value provided is based on the the sublist size + the amount of free space in the unerlying array, but adjust the value being submitted to the parent list so it is based on parent.Capacity (or the equivalent calculation using its fields).
3. EnsureCapacity(int) - Assume the value provided is based on the the sublist size + the amount of free space in the unerlying array, and use the same adjustment as item 2 when passing the value to parent.EnsureCapacity(int).

The task also requires adding tests to confirm the behavior of Count, Capacity, and EnsureCapacity() function exactly the same as these members do on a standaline List<T> instance with the same elements. Any ancestor lists' Capacity should also be confirmed to change based on the actions of the SubList<T>.

Note

SubList members that change capacity (Capacity, EnsureCapacity(int) and TrimExcess()) do not affect the _version of a list, so adjusting the underlying array is not considered an edit to the origin list that breaks the SubList. This is because the actual elements remain unchanged even though they are transferred to a new array instance. This behavior is being implemented in #140, which this task depends on.

This will be a breaking behavioral change, so we have to wait for the next major version bump to include it.