Adds head, tail, and isEmpty methods to several objects

This PR adds `head`, `tail`, and `isEmpty` methods on several collection-like objects:
* adds augmentation on `CharSequence`,
* changes the behaviour of augmentation on `List`,
* adds native (java) methods to `Tuple`,
* adds native (java) methods to ranges,
* adds special methods to arrays.

It also introduce a java interface, `gololang.HeadTail<T>`, and makes `Tuple` and ranges to implement it.

These methods behaviour is:
* `isEmpty` tells if the container is empty,
* `head` returns the first element, or `null` if the collection is empty, to allow chaining methods with “elvis” operator `?:`,
* `tail` returns a new object of the same type containing the rest of the elements (or an empty object if empty).

The purpose is to provide to all collection-like (immutable) structures an homogeneous interface suitable for recursive algorithms.

As an example, a generic function computing the size of such an object can be:
```golo
function size = |struct| -> match {
  when struct: isEmpty() then 0
  otherwise 1 + size(struct: tail())
}
```
and the sum of all the elements:
```golo
function sum = |struct| -> match {
  when struct: isEmpty() then 0
  otherwise struct: head() + sum(struct: tail())
}
```
we can manipulate strings with the same aproach:
```golo
function upper = |str| -> match {
  when str: isEmpty() then ""
  otherwise toUpperCase(str: head()) + upper(str: tail()
}
```
The rationale here is to mimic the behavior of functional other languages, where a new structure (or an immutable one) is returned by `tail`. The purpose is to guarantee to be side-effect free, and avoiding aliasing problems among others.
With `Tuple` and range, `this` can be returned since the object are immutable, which is not the case for `CharSequence` (e.g. `StringBuffer`) nor `List`.

BTW, I just realized that `subList` don't return a new list, and thus the guarantee is not provided.
I think that returning a new independent list in this case would be cleaner. What you guys think?
If we decide to drop the side-effect free guarantee, then yes, this could be return in any case of empty structure, but I rather keep the intended behavior.