Simplify Enum API

[ducky64]

Get rid of some cruft exposed in #373

This also allows Bits.fromtInt(...) to be removed. Yay!

All old APIs (with some new restrictions, rocket still works fine) are preserved without deprecation in Chisel._, aside from the non-compile-time-checkable Map[] enum constructor which probably should have been deprecated during chisel2. The Map[] enums have been removed from chisel3._ without deprecation.

The new restriction is that nodeType (legacy API) may only be of UInt type with unspecified width. Note that Bits() creates a UInt, and if you can't control the enum values, it makes little sense to specify a bitwidth.

[aswaterman]

Why are the Symbol-based enums deprecated in the compatibility layer? (I'm not aware of anyone who uses them; I'm just trying to understand why it is OK to remove features from the compatibility layer.)

Otherwise looks great.

[ducky64]

Scala can't check a map access during compile time (unlike the List-based version, which turn into vals that the compiler understands). This just nags people who are still using that to do something safer, I have no plans to actually remove those elements from the compatibility layer.

If you're super against it I'll remove the deprecation tags.

[aswaterman]

I was just trying to understand the rationale. I guess I agree they should be deprecated, even in the compatibility layer.

[ducky64]

I'll document the rationale and that those are not to be removed.

[seldridge]

I'm only just seeing this from a rocket-chip bump on my end.

I'm against the deprecation tags here. Unless something has been fixed upstream with Scala, the Tuple-based approach for Enums hits Scala's limit of 22 on Tuple sizes. The only way that I know of to get around this is to use the List-based version (ignoring the fact that I idiotically have a legacy state machine with > 22 states...).

Thanks for keeping this support in, nonetheless!