Support Tuple#[](Range) with compile-time range literals

[HertzDevil]

Tuple#[](index : Int) returns the element in the proper type if index is an integer literal known at compile-time. This PR adds a Tuple#[](range : Range) pseudo-overload that only supports compile-time range literals, and returns the elements in a proper sub-tuple type:

tuple = {1, "hello", 'x'}
v = tuple[0..1] # => {1, "hello"}
typeof(v)       # => Tuple(Int32, String)

i = 0
tuple[i..1] # Error: Tuple#[](Range) can only be called with range literals known at compile-time

i = 0..1
tuple[i] # Error: Tuple#[](Range) can only be called with range literals known at compile-time

The motivation is to enable #132 for Tuple values on the RHS, without creating temporary Arrays: (only one layer of decomposition is considered here)

a, *b, c = {1, 2, 3, 4, 5}
a # => 1
b # => {2, 3, 4}
c # => 5

It is assumed that the Crystal compiler should transform the above multi-assign expression into the following, in a purely syntactic manner:

__temp = {1, 2, 3, 4, 5}
a = __temp[0]
b = __temp[1..-2] # => {2, 3, 4}
c = __temp[-1]

The method supports incomplete and exclusive ranges to match the behaviour of other #[](Range) methods, even though the expansion here doesn't require them.

The range index corresponding to the splat variable is always known at compile-time, because it can be deduced from the number of non-splat variables before and after it; thus it suffices to implement the special case for Tuples where this range is a constant expression. (The same syntactic transformation already works out of the box for types that implement #[](Range), like Array.)

On the other hand, the only sensible return type of Tuple(*T)#[](Range) for runtime range arguments is Array(Union(*T)). This PR does not address this discrepancy at all, that's left to #7619. Method lookup bypasses prelude definitions of (Named)Tuple#[] if a compile-time indexer is found, so the compile-time error seen in the top example will not be triggered by constant range literals.

The documentation for this method does not take #10243 into account.

Also see the Gitter discussion that led up to this.

[asterite]

It's so convenient that implementing [] with range is actually done by using [] with a range :-)

When I initially thought about this I thought it would be more complex because of all the indexing logic involved... but it's already there!

[asterite]

I think this is fine for now. But eventually returning an Array is fine too.

[asterite]

This is great!! I left a couple of optional suggestions.