TIR: Intrinsic overhaul, remove hash-intrinsics and make everything more declarative

[kontheocharis]

• Both intrinsics and primitives are now declared in hash_tir::intrinsics::definitions in a declarative syntax that mirrors Hash.
• The macro which accepts this DSL generates various convenient items for using and referencing these definitions.
• To represent intrinsics in the TIR, a new term Term::Intrinsic is added, which accepts a single enum argument that represents the chosen intrinsic.
• There is no longer dynamic dispatch for calling intrinsics, which should improve compile-time performance.
• Intrinsics are now allowed to return Ok(None) to signal that the call to the intrinsic cannot be simplified.

Closes #963

@feds01 I have left a @@Todo in the function discoverer for lowering, I am not sure if I should discover the intrinsics as well or that isn't needed anymore.

[feds01]

Haha, verbose naming 💯

I feel like we should unify operators in hash-source, especially since we will kind of need to do that if we want to share using the Const representation across the compiler. Perhaps, even define it in hash-token?

It would eliminate:

• ir::BinOp ir::UnOp
• ast::BinOp ast::UnOp
• tir::BinOp tir::UnOp

But maybe the separation makes sense?

[kontheocharis]

I think it's a bit different because the operators defined in the AST do not necessarily correlate with the "intrinsic" operations that can be defined on TIR terms. For example, with the new constant stuff a lot of the intrinsics will greatly simplify/become redundant. I think I will first adapt to Const in another PR and then we can consider this separation more.

[feds01]

When we do integrate the new constant stuff, we will still have to define some kind of common operator kinds, I guess for now the IR can just rely on them and the TIR can define conversions for them.

[kontheocharis]

Okay. I agree that there should be some unification here.. Yet another todo item