Implement internal synthesis API

[kiranandcode]

Implements an internal synthesis API. This API is implemented as a Encodable[Callable] instance, which implements decode by calling a series of operations, parse, compile, exec from an evaluation module:

@defop
def parse(source: str, filename: str) -> ast.AST:
    """
    Parse source text into an AST.

    source: The Python source code to parse.
    filename: The filename recorded in the resulting AST for tracebacks and tooling.

    Returns the parsed AST.
    """
    raise TypeError("An eval provider must be installed in order to parse code.")


@defop
def compile(module: ast.AST, filename: str) -> CodeType:
    """
    Compile an AST into a Python code object.

    module: The AST to compile (typically produced by parse()).
    filename: The filename recorded in the resulting code object (CodeType.co_filename), used in tracebacks and by inspect.getsource().

    Returns the compiled code object.
    """
    raise TypeError("An eval provider must be installed in order to compile code.")


@defop
def exec(
    bytecode: CodeType,
    env: MutableMapping[str, Any],
) -> None:
    """
    Execute a compiled code object.

    bytecode: A code object to execute (typically produced by compile()).
    env: The namespace mapping used during execution.
    """
    raise TypeError("An eval provider must be installed in order to execute code.")

For testing, this also adds a UnsafeEvalProvider which provides naive implementations of these by shelling out to the builtin python implementations of each without further checking.

[kiranandcode]

Questions: Should these evaluation functions take in the type of the expected result? If we plan to implement providers that do type checking etc. then maybe we should? I think these should go in compile?

[eb8680]

I left a bunch of comments below, but one common theme is whether this API is compatible with a metacircular evaluator #503

[eb8680]

Questions: Should these evaluation functions take in the type of the expected result? If we plan to implement providers that do type checking etc. then maybe we should? I think these should go in compile?

The expected result type needs to be communicated to the LLM API as well, so I think this data and validation logic probably need to live in the result of type_to_encodable_type(return_annotation) somehow.

[eb8680]

Looks good!

[kiranandcode]

awesome, will merge once tests pass!