Migrate the frontend to use the new HIR2

[greenhat]

Compiled notes from PR comments:

anon namespace

Rather than using the Anon namespace, we should translate symbol names as described in the Component Translation discussion. The gist is that the WIT package name becomes the LibraryNamespace (specifically the User variant), sans version, items exported from the component use the export name as the first non-namespace path component, and so on (i.e. functions exported from an exported interface are additional components). Future changes to LibraryPath will make the syntax for fully-qualified paths a bit more like WIT identifiers, but for now the main thing we want to do is translate them in a way that retains useful semantics in Miden Assembly. We've largely already discussed this, but I'm just reiterating it here since it is relevant to decisions documented in this PR
Likewise, the way in which module/function names are recovered I believe will need to be changed, but we can do that when merging the new IR into the frontend. This is also described in the Component Translation discussion, but essentially we can recover the original WIT interfaces (and their names/exports) using the component instances exported from the top-level component

from #353 :

Generate synthetic functions for Wasm CM canon lift/lower in the frontend

See #357 comments for more details.

Core Wasm module translation (for Miden VM program)

Preview Give feedback

1. translate simple(integer addition) function
2. translate fib program
3. fix the rest of the Wasm ops translation and restore code_translator::tests (commented)
4. translate Call op
5. translate globals and data segments
6. translate BrTable
7. translate If/Else (not used by rustc)

Wasm component translation (for accounts, note scripts, etc.)

Preview Give feedback

1. translate felt intrinsics
2. translate stdlib calls (ABI transformations)
3. translate Wasm CM, CanonLift and CanonLower synthetic functions
4. translate miden tx kernel calls (ABI transformations)

[bitwalker]

Here's another comment that you may find useful, that more clearly defines ABI and calling convention terminology, and how I envision us approaching those concepts in the compiler.

Essentially, ABI details are largely implicit, and only relevant during code generation. Calling convention details are defined in terms of the ABI, and are also largely irrelevant until code generation, except in terms of validation (i.e. that function signatures are valid according to their assigned convention), and to the extent that they are used to derive other information (e.g. function calls to a CanonLift function must be performed using call rather than exec). We do not need to explicitly encode ABI details in the IR anywhere.