The unary type is hacky and broken

[SnirkImmington]

The issue

There are several issues which cause ICEs around the unary/void/() type. The compiler may panic in a few ways with code that attempts to use the result of a function which ends with a return void/plain return. The only place this type can be expressed in code is as a return type of a function without a -> arrow. Consider the following definition:

fn foo()
    return

• Assigning the result of this call to a variable, let x = foo(), causes an error in the identifier as it doesn't know the type of () for x
• Attempting to call return foo() also errors for different reasons

Why we can't fix this

We can't represent the type of () in LLVM. Although #85 was able to fix the direct case of foo(), we want the result of this to eventually be a real unary type () in Snirk and emit LLVM code around this.

Fixing these issues is blocked on an AST representation/pass that decouples the main AST from LLVM in order to handle these cases properly on the compilation side.

[SnirkImmington]

I'm reassigning this to status: blocked over on-hold given that I want to wait for a new IR, so this fix is blocked on that change.