Tuple-like structs and struct-like enum options

[Hugobros3]

This PR adds support for "tuple-like" structures and "struct-like" enum options, as described in https://github.com/AnyDSL/artic/projects/7. This also includes "empty" tuple-like structs, which do not have either parentheses or brackets following them.

struct S { x: i32 }
struct T(i32, f32); // new
struct E; // new

enum E {
  A,
  B(i32),
  C { x: i32 } // new
}

The syntax for constructing and matching on structs or enum options has to match the syntax used when declaring them: This means you cannot initialize something like struct S { x: f32, y: f32, z: f32 } with S(0.0, 0.0, 0.0). Likewise you cannot access the fields of a tuple-like struct by projection (ie s.0), instead you have to match and deconstruct them like tuples instead. It is not possible to match/deconstruct an empty tuple-like struct, and such an action would be pointless anyway since an empty struct carries no information.

In effect those changes make the different data constructor syntaxes (nothing, parentheses with ordered fields and curly brackets with named fields) orthogonal to structs and enums types. We now have "record" and "call" syntax for (de)constructing data, so therefore in the source this is reflected by renaming the AST nodes StructExpr/StructPtrn to RecordExpr/RecordPtrn and EnumPtrn to CallPtrn (matching the existing CallExpr).

[madmann91]

For reference, from our discussion:

• StructDecl should hold const EnumDecl* parent, and provide size_t enum_variant_index as a function, not a member,
• RecordPtrn::needs_ctor_matching should be a function as well (it's in fact equal to match_app<EnumType>(record_ptrn->type).second),
• In general, adding redundant properties to the AST should be avoided,
• Replace:

  auto [type_app, struct_type] = match_app<StructType>(path.type);
  auto [type_app2, enum_type] = match_app<EnumType>(path.type);

  by

  auto [_, struct_type] = match_app<StructType>(path.type);
  auto [__, enum_type] = match_app<EnumType>(path.type);
  auto type_app = path.type->isa<TypeApp>();

• Do not infer nodes twice, like here: https://github.com/AnyDSL/artic/blob/tuple-like-struct/src/check.cpp#L1521
• Make sure coverage is not worse than before using make coverage
• Do not introduce custom error messages unless absolutely necessary. Chances are your error can be covered by an existing error message (see e.g. https://github.com/AnyDSL/artic/blob/tuple-like-struct/src/check.cpp#L913).
• Disallow capturing an enumeration variant as a function, as in

  enum E { A(i32) }
  fn test() { let f = E::A; f(1) }

[Hugobros3]

I still have to look into coverage, and fix the docs

[Hugobros3]

It occurred to me I can simplify the codegen for constructing tuple-like enum variants, since capturing those constructors is no longer legal, we do not have to emit a continuation for those in Path::emit and can directly build the thorin variant in CallExpr::emit, just like I do for record-like enum variant initialization in RecordExpr: https://github.com/AnyDSL/artic/blob/tuple-like-struct/src/emit.cpp#L912