Split binding rules into multiple parts and process built-ins with a subset

[ggiraldez]

This builds on top of #1170 to minimize conflicts from other rule changes.

This splits the contents of the rules.msgb file into several parts which are loaded and ordered at codegen time according to a user-rules.parts file. This is mainly for maintainability purposes.

It also introduces a separate system-rules.parts which is a subset of all the binding rules and can be used to process the built-ins source file a bit faster.

TODO: there's one remaining issue here and that re: error handling in the rules. If there's a problem in the binding rules, the error will be reported for a line number in the merged rules file.

[changeset-bot]

⚠️ No Changeset found

Latest commit: 177c7f0

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[OmarTawfik]

Update from @ggiraldez:

This splits the rules file into several parts that are concatenated at build time to form the final binding rules. This allows us to pick and choose a smaller set of rules for built-ins. The initial intention of this PR was two-fold: 1. improve maintainability and 2. speed up ingestion of built-ins. There is no noticeable speed up of built-ins by using a smaller set of rules, so this is a moot point. This may change after moving all Yul built-ins (#1203). As for improving maintainability, I'm not sure how much this helps, and there is an outstanding problem which is that errors in the rules are reported on the final concatenated file, making it difficult to trace back the original location of the error in the different rules part. Overall, I think this can be put on hold, or disregarded entirely.

Closing for now, since it is just a refactoring with no user-impact. Will leave up to you to re-evaluate that decision once you get back!