Make it explicit which parameter is the return address

[Hugobros3]

Revival of the previous "direct-style" changes in #138.

Unlike #138, this does not make function returns first-class values. Instead, we should have a pass that lowers captured returns to longjmp, implemented as an optional, backend-dependent feature.

---

Thorin uses a CpS IR which naturally represents function returns as continuations. While this form is elegant, it doesn't exactly map to the reality of what our targets can deal with: we actually expect that there is a "return continuation/parameter" that can be known by just looking at the order of the function type (how "deep" the fn() type is). We also expect the return argument to always be to a continuation in the calling scope.

Neither of these assumptions are particularly well enforced, and there is a lot of room for ambiguity. This PR adds a special return_type() type constructor, much like how we also have closure_type(), only functions may have a return type param, and they have only one at most. Continuations (basic blocks) can be transformed into this type using the return_point primop.

By making function returns their own type, we gain the following:

• Ability to enforce at most one return parameter per function
• Ability to ensure we pass something suitable (e.g. a continuation, or another ret param for tail-recursion) as the function return at a call site, and
• Ability to diagnose things we cannot represent for now (capturing a return parameter)
• Ability to represent non-returning functions (e.g. exception handlers) and allow lifting/closure conversion to deal with those without messing up function returns

[Hugobros3]

Ping @m-kurtenacker - you might also be interested in the mothballed closure conversion rewrite

[Hugobros3]

this now builds Rodent 🥳