Fix use of read-only refs on rhs of connect in compatibility mode

[jackkoenig]

#820 changed the implementations of ref and lref to do error checking which was problematic for compatibility mode. I changed legacyConnect to manually use the old implementation of Node(this) which fixes the issue in this instance. I'm a bit worried that other examples of this can creep up so we'll have to be vigilant but I have searched for all uses of ref and lref and I can't see any other problematic cases.

Type of change: bug fix

Impact: no functional change

Development Phase: implementation

Release Notes
Fix bug preventing the use of the output of aggregate Muxes on the rhs of a connection in compatibility mode.

[ucbjrl]

I would like to see checking moved out of pushCommand() and its arguments. Ideally, errors would be diagnosed (and potentially either recovered from or subverted) before getting down to pushCommand().

[jackkoenig]

Are you referring to the implementations of lref and ref? eg.

  // Internal API: returns a ref that can be assigned to, if consistent with the binding
  private[chisel3] def lref: Node = {
    requireIsHardware(this)
    topBindingOpt match {
      case Some(binding: ReadOnlyBinding) => throwException(s"internal error: attempted to generate LHS ref to ReadOnlyBinding $binding")
      case Some(binding: TopBinding) => Node(this)
      case opt => throwException(s"internal error: unknown binding $opt in generating LHS ref")
    }
  }

That was changed by #820 and I think changing it again potentially beyond the scope of this PR. That being said, those appear to be additional internal checks (not the primary checks) and the issues that could cause them from a user perspective are already caught (eg. see all of the requireIsHardwares on Bits operations and https://github.com/freechipsproject/chisel3/blob/9591d690f5a3d71fd5de7a0fb2d67a63e8079f48/chiselFrontend/src/main/scala/chisel3/core/Data.scala#L296)

[ucbjrl]

Ok - for both scope and error issues.

I defer to @ducky64 for approval.

[ducky64]

If this works, this appears fine (mostly because this is limited to legacyConnect). That being said, this could potentially create odd behavior, and this pattern was what led to something like true.B.asClock erroring out in FIRRTL.

[jackkoenig]

From compatibility mode's perspective, several things error out in FIRRTL so it's fine 😃