Merge: Fix generic parameter names

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

Nowadays, I think it is a nonoptimal 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 but names attached to the classdef cause some meta-model nightmares and a workaround was to internally name parameters with their rank in the class.
But nobody liked error message like `got Foo#0 but expected Bar#2`

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 bad idea that names of services can vary through refinement.

Therefore, this PR moves 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:
~~~.nit
redef class Array # no E declared here
   fun pushshift(e: E):E do # but used here
      add(e)
      return shift
   end
end
~~~

Pull-Request: #781
Reviewed-by: Alexandre Terrasa <alexandre@moz-code.org>
Reviewed-by: Alexis Laferrière <alexis.laf@xymus.net>