Discussion of TypeTuple naming

[Diggory]

I gather this has been discussed before and even a potential 
solution submitted 
(https://github.com/D-Programming-Language/phobos/pull/780)

However it was dismissed due to too much existing code being 
broken.

I'd like to suggest a slightly less severe change which should 
still fix the issues with TypeTuple:
https://github.com/D-Programming-Language/phobos/pull/1309

It introduces a new template, StaticTuple which can store any 
template parameters. The two templates are exactly equivalent 
except that TypeTuple checks that its parameters are actually 
types, so StaticTuple!(int, float) == TypeTuple!(int, float).

Reasons for the change:
- Tuples seem to confuse everyone trying to learn D, the 
inconsistency in TypeTuples is a big part of that. Naming the new 
type "StaticTuple" makes it abundantly clear that the built in 
"Tuple" type is for storing multiple values together at runtime 
while a "StaticTuple" is a similar construction but for compile 
time. It then follows directly that "TypeTuple" is a particular 
type of "StaticTuple" for dealing with types.

- The current functionality of using TypeTuples with non-types is 
extremely useful and yet completely undocumented. This change 
means that if some code expects a StaticTuple we can be safe to 
assume that passing it non-types will be fine, and it also opens 
of the doors for other specialized versions of StaticTuple such 
as ExpressionTuple. I have avoided doing anything other than the 
most basic addition of StaticTuple in this pull request as 
further improvements are a separate issue that can be dealt with 
later.

- Unless we plan to stick to the current absurd and confusing 
naming for TypeTuple forever, it's better to make the change 
sooner rather than later.

Reasons why this change is not detrimental:
- The result of the change is zero existing code actually failing 
to compile. TypeTuple will simply show a deprecation warning if 
used with non-types.

- If even a deprecation warning is too much an arbitrarily large 
existing code-base can be fixed using a one off find and replace.

- The new template is also still in the "std.typetuple" module. 
This is not ideal but it is also not a problem - it's common for 
a module to contain related types in addition to the one it's 
named after.

- Any code that does use non-types with TypeTuple is using 
undocumented behaviour. Making undocumented behaviour deprecated 
is a very reasonable change even in the most stable of languages, 
so arguing that D is supposed to be stable and that this breaks 
too much is not a very convincing argument.

- Almost all uses of TypeTuple are for dealing with types and so 
will be completely unaffected by the change.

- There's no necessity to ever actually completely remove the 
deprecated behaviour, the deprecation warning is enough. It's not 
like code only has X amount of time to change its behaviour to 
the new system.