Allow user-defined stack types that aren't value types

[yorickpeterse]

Commit 8ca46bf adds support for defining stack allocated value types using the syntax class inline Name { ... }. Using that syntax, the types are restricted to storing other inline types such as Int or a user-defined inline type.

This PR extends this setup to allow for stack types that can store heap types. The result is the following:

• class A defines a heap allocated type subject to single ownership
• class inline A defines a stack allocated type subject to single ownership
• class copy A defines a stack allocated, immutable value type that is copied upon a move (i.e. the old class inline A setup)

Relevant issues

• Introduce support for user-defined, stack allocated value types #750
• Make enums and tuples stack allocated types #780

TODO

• Swap the inline keyword with the copy keyword
• Rename inline_* diagnostics tests to copy_*
• Ensure inline types are subject to move and not copy semantics
• Disallow assigning fields new values for both inline and copy types
• Generate a dropper for inline types but not copy types
• Add inline enum support
  • Using inline for Option results in a shape missing compiler panic
    • This seems to happen when nesting inline or copy types (e.g. Option[Option[Int]])
    • If you nest an empty copy type, we seem to trigger an LLVM SEGV, probably due to the size not being correct
  • With that fixed, we now seem to generate duplicate symbol names for different classes
    • It seems that two different types (e.g. Option[A] and Option[B]) result in the same final symbol names, suggesting we're perhaps not taking into account shapes of sub types?
  • Fix drop error when running the standard library tests
    • We seem to generate a specialization key that includes stack shapes that store unspecialized ClassInstance types, seemingly resulting in the wrong methods being used for calls
• Handle inline and copy types with a size of zero (= no fields)
  • Enforce a minimum size of 1 bit at the LLVM level
  • Ensure such values can in fact be passed around
• Generate an $increment method for inline types, and call this when borrowing an inline type
  • This method calls $increment on any inline types stored in self, and for heap types directly increments the borrow count
  • This method must be an inline method
• Generate a $decrement method for inline types, and call this when dropping a borrow of an inline type
  • This method calls $decrement on any inline types stored in self, and for heap types directly decrements the borrow count
  • This method must be an inline method
• Reuse logic between GenerateDropper and GenerateInlineMethods
• Handle cloning inline types at the MIR level
• Add the shapes StackRef and StackMut for borrows of inline types
• Allow fn mut methods for inline types, as heap values can still be mutated in place as expected
• Don't collapse ref T and mut T into T for inline types, only do that for copy types
• Specialize the StackRef and StackMut shapes such that they call $increment/$decrement
• Add inko fmt tests
• Add diagnostic tests
• Figure out why making Result an inline type results in a segfault when running the standard library tests
• Figure out why making std.sys.Stdout an inline type crashes the std.sys tests
• Figure out why making std.stdio.Stdout an inline type crashes the test suite
• Go over the standard library types and mark them as inline where appropriate, commit this separately from the main set of changes

After the necessary code changes are made:

• Add Tree sitter support for the copy keyword: inko-lang/tree-sitter-inko@1419efb
• Add Vim syntax support for the copy keyword
• Add VS Code syntax support for the copy keyword
• Update the documentation