Fix stack trace trimming across Driver/ChiselStage

[seldridge]

Fix bug in stack trace trimming behavior. Now, the following is what
happens:

1. The Builder, if catching accumulated errors, will now throw a
   ChiselException with a Scala-trimmed Stack trace. Previously, this
   would throw the full excpetion.
2. The Elaborate phase handles stack trace trimming. By default, any
   Throwable thrown during elaboration will have its stack
   trace mutably trimmed and is rethrown. A logger.error is printed
   stating that there was an error during elaboration and how the user
   can turn on the full stack trace. If the --full-stacktrace option
   is on, then the Throwable is not caught and only the first
   logger.error (saying that elaboration failed) will be printed.
3. ChiselStage (the class), ChiselStage$ (the object), and ChiselMain
   all inherit the behavior of (2).

Mutable stack trace trimming behavior is moved into an implicit
class (previously this was defined on ChiselException only) so this
can be applied to any Throwable.

No StageErrors are now thrown anymore. However, StageErrors may still
be caught by ChiselMain (since it is a StageMain).

Testing is added for ChiselMain, ChiselStage, and ChiselStage$ to test
all this behavior.

Fixes #1763. (I think...)

Contributor Checklist

• Did you add Scaladoc to every public function/method?
• 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 add appropriate documentation in docs/src?
• 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

• bug fix

• code refactoring

API Impact

None for actual user-facing API. Some exception behavior is changed.

Backend Code Generation Impact

None.

Desired Merge Strategy

• Squash: The PR will be squashed and merged (choose this if you have no preference.

Release Notes

Reviewer Checklist (only modified by reviewer)

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

[jackkoenig]

Any Driver work here is going to conflict with #1730, any thoughts @seldridge and @sequencer?

[seldridge]

No real conflict as far as I'm concerned. If #1730 goes first, then this PR should drop its Driver changes (because it doesn't exist). If this goes before #1730, then #1730 should still remove the driver.

[sequencer]

I think if Driver will be dropped at last. So let's get #1730 merged first?

[seldridge]

There are some weird interactions with capturing stdout and checking it seemingly having a weird interaction with the Logger. I'm also refactoring this so that it can be applied to the master branch and to 3.4.x. (I was incorrect above, this needs to be backported so that we can fix this in 3.4.3.)

[seldridge]

Manual backport to 3.4.x is here: #1773.

[jackkoenig]

This is fantastic, I have a few comments I'd like answered but the tests are great and I love the simplified and unified functionality

[seldridge]

Ready for re-review. Also, the backport (#1773) should be reviewed, too. I'm currently maintaining the backport and then cherry-picking onto master for this PR.

[jackkoenig]

LGTM! Nice work.