[FIRRTL][RefType] Reset inference should fail if would fail without references

// BADNESS:
firrtl.circuit "RefResetBadness" {
  firrtl.module private @SendReset(in %r: !firrtl.reset, out %ref: !firrtl.ref<reset>) {
    %ref_r = firrtl.ref.send %r : !firrtl.reset
    firrtl.strictconnect %ref, %ref_r : !firrtl.ref<reset>
    // firrtl.ref.define %ref, %ref_r : !firrtl.ref<reset>
  }
  firrtl.module @RefResetBadness(in %r: !firrtl.reset, out %reset : !firrtl.asyncreset) {
    %s_r, %s_ref = firrtl.instance s @SendReset(in r: !firrtl.reset, out ref: !firrtl.ref<reset>)
    firrtl.connect %s_r, %r : !firrtl.reset, !firrtl.reset
    %res_reset = firrtl.ref.resolve %s_ref : !firrtl.ref<reset>
    firrtl.connect %reset, %res_reset : !firrtl.asyncreset, !firrtl.reset
  }
}

Essentially, this plumbs around an uninferred reset through a reference, which after resolving is connected to an AsyncReset.

This currently works, as it would if this was a normal connection.

To ensure instrumenting with references doesn't (cannot) influence the generated hardware, this should be rejected. If the design is invalid without resets, it should be invalid with them, to avoid masking errors or introducing unexpected impact from, for example, building used by a test bench / unit test. Resets can be inferred the other way, however.

This is the proposed behavior in the current Reference Types FIRRTL proposal, see:

https://github.com/chipsalliance/firrtl-spec/pull/75/files#diff-bc6661da34ecae62fbe724bb93fd69b91a7f81143f2683a81163231de7e3b545R644-R675

Start with the FIRRTL RefType reset-inference behavior illustrated by the RefResetBadness example, then compare it with the linked Reference Types FIRRTL proposal. Done means the shown design is rejected when reference resolution would produce an invalid reset connection, while the permitted opposite reset inference remains accepted.