Reversing order of arguments to bit extraction gives terrible error message

h/t @erikdanie for finding this.

**Type of issue**: Bug Report

**Please provide the steps to reproduce the problem:**
```scala
class Example extends Module {
val in = IO(Input(UInt(8.W)))
val out = IO(Output(UInt()))

out := in(0, 3) // should be in(3, 0)
}
```
(https://scastie.scala-lang.org/8lxH7qW6QzCxQ1MOZXS2qQ)

**What is the current behavior?**

Gives:
```
java.lang.IllegalArgumentException: requirement failed
at ... ()
at Playground$Example$$anonfun$3.apply(main.scala:9)
at Playground$Example$$anonfun$3.apply(main.scala:9)
at chisel3.Data.$anonfun$$colon$eq$1(Data.scala:780)
```

Which is clearly useless.

**What is the expected behavior?**

There is a decent error message here: https://github.com/chipsalliance/chisel3/blob/fc970ca28e562f2ea3ba160963604ea3deaf3467/core/src/main/scala/chisel3/Bits.scala#L188
But it's a _recoverable_ error (`Builder.error`) so Chisel keeps executing then hits a requirement elsewhere which is hiding the better error message.

There's a good argument that any `NonFatal` error in Chisel elaboration should be caught and then if there are errors, we should report them in case our attempt at continuing execution is causing a later error that masks the original one.

**Other Information**

**What is the use case for changing the behavior?**

Better error messages

Reproduce the reversed bit extraction from the Scala example or its Scastie link, then read the error handling at core/src/main/scala/chisel3/Bits.scala#L188 and the Data.scala:780 stack entry. Done means the useful bit-order error is surfaced instead of a later requirement failure masking it; the issue leaves the broader elaboration error-handling design open.

Written by the indexing model from the issue text.