Added support for successive <> operations overriding each other.

I implemented and tested out both varieties of overriding bulk connects, letting `:=` override `<>` and letting `<>` override `<>`, and I think a good case can be made for the latter.

If `:=`/`procAssign` were special-cased to override `<>`/`assign` only when no when condition exists, this special overriding assignment would necessarily not be able to be overridden again by a conditional `:=`, making its meaning more similar to `assign` than `procAssign`.

The second way has the tradeoff of requiring multiple calls to `assign` to succeed, but allowing overriding essentially implies that this is okay. It enforces a few rules:

1. `<>` can override `<>` at any part of the hierarchy
2. `<>` cannot be conditional
3. `:=` cannot override `<>`

Rule 2 should be enforced even with the existing Chisel semantics, but this case currently produces incorrect results silently. This change also adds a check for this.