Compose Interpreter and State

[dcbaker]

The Interpreter is an all-knowing object that has too many responsibilities. This creates a bunch of problems I want to solve, particularly for getting my series to build subproject for both machines running. This series addresses that by moving the mutable state of the Interpreter that is not specifically interpreter details (like interpreter methods) into a separate state object. This provides a number of potential advantages as followups:

• This could replace the ModuleState object as the state parameter
• This can be passed into KwargInfo.validate and KwargInfo.convert to provide information like the current subdir, which would allow certain kinds of conversions not currently possible today like converting strings to Files or IncludeDirectories
• This should allow de-coupling helper methods that are useful outside of the interpreter like source_strings_to_files

This also fixes an issue that currently exists where a failing, optional, subproject, alters the global state in a way that cannot be rolled back, and has the potential to cause the build to fail. Because the state is a separate, composed, object it can be snapshot and replaced, allowing for transactional rollbacks.

Some of these cleanups I've started on, but this series is already 42 patches long.

I have taken great pains to ensure that everything works on every commit, with the hope that if necessary we can merge this in smaller pieces.

edit: This is based on: https://github.com/mesonbuild/meson/pull/12621

[dcbaker]

Apparently there are still some issues with non-unit tests

[dcbaker]

Rebased on main, next up is to deal with review :)

[tristan957]

I gave your PR a good look the other day. I really like it, and would approve it, but I think it would be good to get a review from one of @xclaesse, @eli-schwartz, or @jpakkane to confirm that the design is good for the project.

[jpakkane]

In the option refactor branch I found out that implementing things with inheritance makes things rigid and hard to change. In general we should be prefering free standing functions. In this case LocalState is only inherited once.

[dcbaker]

Okay, @jpakkane you gave me the motivation to finish the AstInterpreter and the IntrospectionInterpreter, and rework the State class a little bit, so there are some more subclasses (and less Interpreters being initialized!)

Again, I'd really like to look at what's in the Interpreter State vs the CoreData vs Environment vs Build to see what's duplicated, and what we can do to better organize all of our state