Extraction as a top-level command in the frontend for the new backend

[FTRobbin]

This PR implements extraction as a top-level command in the frontend. It uses the default additive tree cost model and can only be triggered through (extract [term] [variant]).

Implementation overview:

• Extract as an action has been removed.
• query-extract as a top-level command has also been removed.
• Extract is now a Command and is interpreted in the frontend run_command. Extract first runs two backend queries to resolve the eclass and the number of variants to be extracted and then calls ExtractorAlter to perform the extraction.
• ExtractorAlter first needs to be initialized by passing the list of rootsorts to be extracted. It computes all relevant costs using Bellman-Ford and remembers the necessary information for reconstruction in this step. Then, it can be queried multiple times to reconstruct the terms in termdags. It does not hold a reference to EGraph, so it can be reused as long as the relevant tables do not change.
• As an optimization, in the initialization step, ExtractorAlter first performs a BFS on the sorts to filter out tables unreachable from the root sort.
• In the Bellman-Ford loop, it calls inner_sorts and inner_values on the sorts to unpack containers and calls the cost model for primitive, container, and function costs.
• After Bellman-Ford finds a fixpoint, ExtractorAlter enumerates all rows again to copy information for reconstruction. Ties are broken arbitrarily.
• For extracting a single lowest-cost term, it recursively reconstructs the lowest-cost enode for each eclass used in the lowest-cost enode of the root eclass and writes into a TermDag struct.
• For extracting multiple "diverse" variants, it extracts the multiple enodes of the root eclass, in the order of lowest costs, using a single lowest-cost enode for other classes.

Additional remarks:

• This implementation does not involve concurrency control or tunneling between the frontend and the backend, so the code logic is simplified compared to Extract action for the new backend #562.
• This new architecture potentially allows extraction to be used more easily from RustAPI.
• This implementation opens up the possibility of reusing extractor results, potentially subsuming Reuse Extractor whenever possible #563 after the new backend merge.
• A caveat is that there is no easy way to port the old Extractor to this new architecture. So, no extraction in the old backend after this PR.

[Alex-Fischman]

I have not reviewed the actual extraction algorithm. My comments are about style and software engineering.

[oflatt]

did a quick and rough review

[oflatt]

nice!

[oflatt]

oops, saw an opportunity

[oflatt]

never mind, the external function is necessary

[Alex-Fischman]

All of my comments have been resolved