Fixes #2422

This PR works but I want to discuss this a bit before merging this.

Right now lib structs, unions and funs are restricted to either primitive types (Int32, Float32, etc.), pointers, enums, and structs and unions inside lib types. You can't use a "regular" crystal class or struct.

With this PR one can now mark a crystal struct (defined outside a lib declaration) as @[Extern], and then the compiler lets you use this type in the above places.

lib structs and unions automatically receive getters and setters for each field, and they get an empty constructor that sets the type to zero (memzero):

lib LibFoo
  struct Foo
    x : Int32
    y : Int32
  end
end

foo = LibFoo::Foo.new
p foo # => LibFoo::Foo(@x=0, @y=0)

In contrast, and this is what I'd like to discuss, a regular struct marked with @[Extern] follows crystal rules, and the compiler will complain if declaring an instance variable and not properly initializing it. However, one can use @x = uninitialized ... to mark that variable as "unsafe" and not needing a check from the compiler.

Alternatively, we could automatically generate getters and setters for every instance variable, but I feel this is less safe and nice. One disadvantage of not doing this is that for C struct/union getters the compiler will invoke to_unsafe to do numeric conversions, but without these getters one would have to do these conversions.

But, I think that this extern structs will probably be used with types that are created by lib functions, and you rarely need to set their instance variables, but instead you query them (or maybe you use them but don't let users query them). And in any case you can define setters and do a manual conversion there, if needed.

One can also mark a struct with @[Extern(union: true)], and now the struct will behave as a C union. For example:

@[Extern(union: true)]
struct Int64OrFloat64
  @int = uninitialized Int64
  @float = uninitialized Float64

  property int
  property float
end

x = Int64OrFloat64.new
x.int = 10_i64
p x # => Int64OrFloat64(@int=10, @float=4.9406564584124654e-323)

With this new @[Extern] attribute writing C bindings that have lots of structs and unions is greatly simplified, as one doesn't need to wrap these in a Crystal struct. There is also no need to define a to_unsafe because the type is already the type that's passed directly to C. I checked if this could be applied to, for example, the LLVM bindings and yes, and many LLVM:Value.new(LibLLVM.get_some_value) are replaced with just LibLLVM.get_some_value. But in this case the gain is very little. I think libraries such as SDL or SFML will benefit more from this because they expose structs that can be accessed directly, not only via an opaque pointer.

One missing thing mentioned in #2422 is that, in order to keep binary compatibility with the C library, one shouldn't be able to add more instance variables to such structs. We could trust the user not to do so, or simply allow instance variable declarations on the first definition of the type, disallowing adding more instance variables later. For now we can start with the first option and eventually implement the second for a more robust solution.

Thoughts?