Merge: class annotation `autoinit` to explicitly lists initializers.

A suggestion of @Morriar is to use a class-level annotation `autoinit` to list initializers.
It should ne rarely used, in case of conflict for instance, or to restrict the number of initializers (but this could be fragile).

A step towards #785

~~~nit
class A
  var a: Int
  var b: String
end

class B
   autoinit c, b, a
   super A
   var c: Bool
end

var a = new A(10, "foo")
var b = new B(true, "foo", 10)
~~~

Some issues remains, I my require your input on these

* why I am required to put `autoinit` before the `super` clause?
  because the grammar is ugly.
  Maybe I should find a way to enable the `autoinit` clause everywhere in the body of the class?
  This is a grammar issue that can be solved independently I think.
* what are the validity of initializers?
  The first commit is used to discriminate properties that are initializers and those that are not.
  I am not sure if restricting what can be used an initializer makes sense. In fact I really do not know what is the best expressive-but-safe policy here. See the last point for a related issue
* what about clearing the full list of initializers (so no parameters in the new)?
  The annotation `noautoinit` will do the trick.
* what about setters?
  when one writes `class A var x: Int`, in fact the initializer is not the getter `x` but the setter `x=`. It is obvious once one understand that `var a = new A(10)` is just `var a = alloc A; a.x = 10; a.init`.
  However, I chose to implicitly try to search the setter first when given `x` as an element of the `autoinit` clause, so that one can write `autoinit x` instead of the less POLA `autoinit x=` (that also works by the way).
  Unfortunately this kind of heuristic makes the specification more complex, but also prevents one to use a method `x` as an initializer if a method `x=` exists.

Pull-Request: #1158
Reviewed-by: Lucas Bajolet <r4pass@hotmail.com>
Reviewed-by: Alexandre Terrasa <alexandre@moz-code.org>