Implement basic function inlining

[GearsDatapacks]

Closes #3869
This PR implements the basic process of function inlining, without any heuristics to determine which functions to inline, we just use a hardcoded list.
The code for this is pretty much done, so please take a look, but before this is merged there's a few more things we should do:

• Decide on the list of functions we want to use. For now I've chosen a few of the basic result and bool combinators which seem to be the highest value but we should decide if there are any others we want to inline as well.
• Benchmark. We should come up with some benchmarks to determine if the inlining process significantly impacts compiler performance, and if so think about ways to mitigate that.
• Test. I've written some basic codegen tests in the javascript::tests::inlining and erlang::tests::inlining modules, but please suggest any other tests to write also. As well, we should run this version of the compiler on lots of existing packages to make sure nothing is broken.

[giacomocavalieri]

This is amazing, and the code was such a pleasure to read!! I've left just a couple of nits

[DanielSherlock]

Hey, sorry for the uninvited comments! This is a really cool improvement and I was curious to peek behind the scenes...

[GearsDatapacks]

Not sure if this is the right way to go about it, but I've added a special always_inline function, which will always be inlined in test code, so we can easily test specific scenarios with custom functions.

[lpil]

This is looking really good!

Have you done any measuring of the impact on this change on Gleam programs? Performance and code size are interesting, including with combinations of minification, gzip and/or brotoli for JavaScript. We want to make sure that we haven't in some places caused unexpected problems.