privat/nit — pull request #781 by privat (2014-09-26 04:12:45+00:00)
Title: Fix generic parameter names

Since the beginning of Nit and class refinement, formal parameter names where attached to local-classes (MClassDef). So giving the ability to use different names in various class refinements.
This was done in a analogous way with parameters in methods since one can change their names in redefinitions or methods.

Nowdays, I thing it is a unoptimal idea since this renaming ability is unused, worse it is considered bad since it makes code more complex to read: one do not want to have distinct vocabulary for the same class but in distinct modules.

Moreover, having parameters attached to the class and names attached to the classdef cause some meta-model nightmares and a workaround was to name parameter with their rank in the class.
But nobody liked error message like `got Foo#4 but expected Bar#45`

A last issue is that, for a dynamic type system point of view, the formal types can be exposed as object-oriented-services. For instance, in potential construction like `if x isa y.T then ...`, where `T` is a formal type defined in the static class of `y`, and that will be resolved at runtime.
Thus, it is a bas idea that names of services can vary trough refinement.

Therefore, this PR move the name of generic formal parameters in `MParameterType`, kill the ugly `MClassDef::parameter_names`, rationalize `MClass` and `MClassDef` construction, and update all the client code.

This PR gives also two bonuses:

* `name` and `to_s` in `MParameterType` make sense so type-related error messages are more readable.
* Since the names of formal parameters become invariant in refinements, their declaration become optional:
~~~
redef Array
fun pushshift(e: E):E do # E is E in all Arrays
add(e)
return shift
end
end
~~~