Splitting builtin support between the IR and the backend

As per the title, I think it would be paramount to split the builtins support between the backend and the middleend, the reason that I propose this is fourfold:

1. By splitting the support to the middleend initially, we will be able to optimize the register usage for individual uses, preventing the expensive calling convention setups for fastcall.
2. Depending on the architecture, if there is no instruction-level support, we could theoretically insert an IR-level block for what we want to do and have the optimizer work with that.
3. Some builtins are platform specific, if we mark those builtins in the middle-end we can spit them out and say "Not supported for this platform" and error out because of it
4. Continuing with 4, when there IS a platform specific builtin, we can optimize how we get into a valid state for it and execute the individual instruction, allowing us to support sse intrinsics without having expensive move-arounds (related to #304 in a way).

This is a rather hefty issue so I definitely think this belongs sometime after milestone 4, possibly after milestone 5.

Start by locating how builtin support is currently divided between the compiler's middle-end and backend; the issue does not name specific files or tests. Define the IR boundary for builtins, including register usage and platform-specific support, before changing implementation. Done means backend and middle-end responsibilities are separated, unsupported platform builtins are rejected, and supported instruction-level paths avoid unnecessary calling-convention setup.