//! model during search. The entrypoint for incremental solving is the [Solver<A,ModelLoaded>::solve_mut]
//! let rule_sets = resolve_rule_sets(SolverFamily::Minion, &vec!["Constant".to_string()]).unwrap();
//! // The solver interface is designed to allow adaptors to use multiple-threads / processes if
//! // necessary. Therefore, the callback type requires all variables inside it to have a static
//! // Using the move |x| ... closure syntax, we move one of these references into the closure.
// If incremental solving support is required, also implement a new `ModelModifier`. If this is not
// required, all `ModelModifier` instances required by the SolverAdaptor trait can be replaced with
/// Implementations of this trait aren't directly callable and should be used through [`Solver`] .
/// [`SolverAdaptor`] should follow - **see the top level module documentation and [`Solver`] for
/// A [SolverAdaptor] **may** use whatever threading or process model it likes underneath the hood,
/// Underlying solvers that only have one instance per process (such as Minion) **should** block
/// Implementations of this function **must** call the user provided callback whenever a solution
/// Implementations of this function **must** return [`OpNotSupported`](`ModificationFailure::OpNotSupported`)
/// abstracts over solver-specific datatypes, handling the translation to/from [conjure_core::ast]
/// underlying solver used, the translation of the model to a solver compatible form, how solutions
/// are translated back to [conjure_core::ast] types, and how incremental solving is implemented.
/// As such, there may be multiple [SolverAdaptor] implementations for a single underlying solver:
/// e.g. one adaptor may give solutions in a representation close to the solvers, while another may