[deprecation clean up] remove firrtl.ExecutionOptionsManager

[sequencer]

4163048 should depend on #2428

Contributor Checklist

• Did you add Scaladoc to every public function/method?
• Did you update the FIRRTL spec to include every new feature/behavior?
• Did you add at least one test demonstrating the PR?
• Did you delete any extraneous printlns/debugging code?
• Did you specify the type of improvement?
• Did you state the API impact?
• Did you specify the code generation impact?
• Did you request a desired merge strategy?
• Did you add text to be included in the Release Notes for this change?

Type of Improvement

• code cleanup

API Impact

This removes many APIs that have been deprecated for a long time:
ExecutionOptionsManager and related APIs: ComposableOptions, HasParser, CommonOptions, HasCommonOptions, FirrtlExecutionOptions, HasFirrtlOptions, FirrtlExecutionResult, FirrtlExecutionSuccess, and FirrtlExecutionFailure

It also removes other deprecated APIs using ExecutionOptionsManager: logger.Logger.makeScope and firrtl.stage.DriverCompatibility.firrtlResultView.

Lastly, it deletes non-deprecated OutputConfig, SingleFile, and OneFilePerModule, but these were types only used by ExecutionOptionsManager APIs.

Backend Code Generation Impact

No impact

Desired Merge Strategy

• Squash

Release Notes

Remove ExecutionOptionsManager and related APIs. See #2422 for full list of removed APIs

Reviewer Checklist (only modified by reviewer)

• Did you add the appropriate labels?
• Did you mark the proper milestone (1.2.x, 1.3.0, 1.4.0) ?
• Did you review?
• Did you check whether all relevant Contributor checkboxes have been checked?
• Did you mark as Please Merge?

[jackkoenig]

I added a change that effectively reimplements #1305 in a different way.

Removing the old version of Logger.makeScope (changing the argumentless version to use the one accepting AnnotationSeq) exposed a bug where you can't actually tell if an AnnotationSeq is trying to set the log level or not because it defaults to LogLevel.Warn. I changed everything to default to LogLevel.None, but then have the internals understand that and sub in LogLevel.Warn whenever it's set to LogLevel.None.

One might point out that LogLevel.None implies no logging rather than "unset" and at least one test agrees with that. However, I also noticed that other locations in the code clearly use LogLevel.None as "unset" (see Logger.setOptions), and considering we don't let the user set the log level to None in the CLI, I decided to go with this implementation.

@seldridge I'd appreciate some thoughts from you on this.

[seldridge]

I think your interpretation of LogLevel.None is fine.

A future improvement would fully remove LogLevel.None and set "none" based on "no log level annotation present". Currently, we may be double-encoding this with "no annotation" and LogLevel.None.