A control structure to wrangle settings in drake_config()

[wlandau]

Prework

• Read and abide by drake's code of conduct.
• Search for duplicates among the existing issues, both open and closed.

Description

drake_config() currently returns a giant list of everything make() needs to run. We should probably clean this up internally. Lightweight parameters could go into their own "control" object. I generally find control lists at the API level frustrating, but internally they could reduce clutter. Items to include:

- `cache_path`
- `hash_algorithm`
- `parallelism`
- `jobs`
- `jobs_preprocess`
- `lib_loc`
- `seed`
- `timeout`
- `cpu`
- `elapsed`
- `retries`
- `skip_targets`
- `skip_imports`
- `skip_safety_checks`
- `log_progress`
- `lazy_load`
- `session_info`
- `caching`
- `keep_going`
- `memory_strategy`
- `garbage_collection`
- `console_log_file`
- `cache_log_file`
- `lock_envir`
- `recover`
- `recoverable`
- `packages` (maybe)
- `lib_loc` (maybe)
- `prework` (maybe)
- `progress_hashmap` (maybe)
- `template` (maybe)
- `sleep` (maybe)
- `force` (maybe)

[wlandau]

Deciding against this.config$control would just be another "God object", too wide and fuzzy in scope. When we group together elements of config, we should be more principled. Elements like cache and logger successfully subsume little flags that are in scope (such as verbose). Let's going as we continue to find good reference classes for internals.

[wlandau]

Let's define the scope and implement this.

[wlandau]

config and config$control should get S3 classes.

[wlandau]

Subsuming into #1117.

[wlandau]

Closing for the same reasons as #1191 (comment).