This fixes #2458

This PR makes class variables be inherited from superclasses and included modules. This only means that a class variable is available in a subclass, with the same type as a superclass class variable, but their value is not shared. If you are familiar with Ruby class instance variables, this is the same. This works for modules too (class variables are inherited from including modules). If there are type conflicts the compiler gives an error (there are a few specs in this PR, you can check them).

For example:

class Foo
  @@var = [1, 2, 3]

  def self.var=(@@var)
  end

  def self.var
    @@var
  end
end

class Bar < Foo
end

p Foo.var # => [1, 2, 3]
p Bar.var # => [1, 2, 3]

Foo.var << 4

p Foo.var # => [1, 2, 3, 4]
p Bar.var # => [1, 2, 3]

Bar.var << 5

p Foo.var # => [1, 2, 3, 4]
p Bar.var # => [1, 2, 3, 5]

[Foo.new, Bar.new].each do |foo|
  # Prints [1, 2, 3, 4] first, then [1, 2, 3, 5]
  p foo.class.var
end

Note that the initializer of @@var is not shared between Foo and Bar, they are different instances.

If you think about it, it's very similar to instance variables. When you have @foo = [1, 2, 3] in a class, every instance you create gets a new instance of that array. If you modify @foo in one instance, it doesn't affect other instances. This is the same now for class variables.

Also note that you can iterate a class hierarchy and access a class variable, and the dispatch happens. So this also fixes not being able to access a class variable through a Foo+ type.

There are no plans to include a feature like Ruby's class variables, for two reasons:

1. I believe they are considered dangerous and bug-prone in Ruby (please correct me if this is not the case)
2. One can emulate them by using a separate class/module to hold the class variable. Consider the example in Compiler can't infer seemingly obvious type #2757. It seems that @@strings was supposed to be shared between all descendants. To solve this, instead of providing access to @@strings, one can define a method strings that accesses @@strings in another nested module. This also has the advantage of not having to expose @@strings.

Thoughts before merging this? :-)