Make reinterpret cast conversions (fromBits / asUInt / etc) consistent

[ducky64]

Split of the discussion from #424. I think we want to do the temporary fix first while we discuss how to improve the API.

@sdtwigg 's approach was:

Our approach was the following:

1. asUInt or from[blah] on a Clock is a runtime-exception (iirc FIRRTL doesn't support this at all anyway)
2. Instead of fromBits, Data has an "asTypeOf[T <: Data](model: T): T" since most commonly people were using fromBits to perform a cast and this made all casts look like as[blah]. This also made asTypeOf invert itself. (There are potentially some odd cases when unknown-width SInts are involved; however, it was generally advised to use only known width things under threat of emitting errors later.)
3. asTypeOf uses connectFromUInt(target: UInt) for each element, which basically acts like your proposed fromBits (but without having to worry about which Bits it is). connectFromUInt also doesn't create any wires.

So a concrete (API change) proposal would be:

1. Implement asTypeOf(model) for the fromBits conversions.
2. Deprecate fromBits. It didn't really have an intuitive API.

[ducky64]

We will deprecate fromBits and replace with Data.asTypeOf(model) as per Stephen's approach.

[ducky64]

So the new asTypeOf API has been around for a while, though fromBits hasn't been deprecated yet.

Since fromBits is a Data method, deprecation in chisel3._ only (and not in Chisel._) will likely be difficult. Options include:

• Deprecate fromBits across the board. Legacy users will receive deprecation warnings.
• Remove fromBits from Data._, and use implicit casts (PML pattern) to support fromBits with different implementations in chisel3._ and Chisel._. This will also be the only option to support fromBits in Chisel._ if we want to remove it completely from chisel3._.

[ducky64]

We will try #2 (PML to like FromBits-able) and manually fix up any instances where it breaks existing code.