feat: primitive types are no longer keywords

[asterite]

Description

Problem

No issue, just noticed that Noir doesn't work like Rust in this regards.

Also trivially fixes #8023

This also uncovered an inconsistency in the language: you write let _ = Vec::<i32>::new(); but for strings you currently have to write it like let _ = str<N>::something(); (no :: between str and <). We could accept that inconsistency if we keep parsing primitive types in a special form, or we could improve things now to avoid breaking changes after 1.0. For this, we could maybe first create a PR to allow writing str::<N>::something(); (would parse to a TypePath), give a warning if someone writes str<N> in an expression context, then use the correct syntax in external crates, then this PR wouldn't produce errors anymore.

Summary

In Rust, primitive types like i32, bool, etc., are not keywords. They just resolve to types at the very last moment, after searching through existing data types. In Noir, before this PR, they were keywords. Not anymore.

This isn't super important, but it gives more flexibility to the language. For example:

• a few times in the past I wrote let bool = true; for some quick prototype code, only to find out that that doesn't parse (but it does in Rust)
• if you want to have a factory of values, you couldn't have a function i32 that returned i32. Now you can.
• if you wanted to define a type in your crate called Expr for some reason, you couldn't as it was a keyword
• if you wanted to invoke a method on str, for example str::as_bytes(...), you couldn't, as we'd only parse str followed by generics
• now str<1, 2> is parsed correctly, except that it gives a generics count mismatch error (again, not super important, but it's nice for LSP recovery as that's not a syntax error, just a semantic error)

This also allows us to introduce new primitive types in the future without breaking any code, as users can use any name for their types, for example char, and if we introduce a char type, the char in their code would refer to their char, not the primitive type.

I think this also simplifies the compiler a bit as we no longer need a keyword, an unresolved type, and logic to resolve that unresolved type, for every primitive type. (also: the diff shows that this ends up using less code)

Additional Context

1. To solve a path like i32::default(), which was previously parsed as a TypePath, I needed the same logic to finding direct functions or trait functions in scope that exists somewhere else. There's a bit of code duplication but it's not that much. I couldn't find a way to improve this, but we could capture an issue to try to do it.
2. In Rust you can define struct i32 { ... } which won't conflict with the primitive type i32. But what if you wanted to refer to the primitive type i32 in that same file? You can, using std::primitive::i32. We could do the same by using type aliases (I think!) but that case should be rare so I decided not to do that in this PR.
3. While making this change code like this stared failing: assert!(3 as u8 < 4). It actually fails in Rust too! The reason is that u8 < actually denotes a generic type u8<...>. In Rust you have to write this as assert!((3 as u8) < 4). So this PR would introduce a breaking change. To avoid that, I made the parser not parse generics on the type given to as. However, I think the "correct" thing would be to error like in Rust, especially if in the future we find some use case for casting between other types that aren't primitive types and that might be generics. In that case it'll break code so maybe we should introduce that breaking change before 1.0.

Documentation

Check one:

• No documentation needed.
• Documentation included in this PR.
• [For Experimental Features] Documentation to be submitted in a separate PR.

PR Checklist

• I have tested the changes locally.
• I have formatted the changes with Prettier and/or cargo fmt on default settings.

[TomAFrench]

Quick first pass, there's a few TODOs that have been added to the codebase. Can you resolve these or create issues (and link to them from the codebase)?

[asterite]

Done! All those TODOs are for these two issues:

• Numeric generic types are checked before elaboration #8504
• Revisit UnresolvedType methods #8505

I removed the "TODO: check generics" comments as they are also related to the first issue above (once that's solved, generics will be checked).