[HW] Encoding enum types and values

In case an explicit base type has been defined, we should check whether the requested encoding fits within the specified bitvector.

### Bitvector casting
Integer casting allows interpreting enums as bitvectors and vice versa:

**Q**: Should we only allow bitcasting on enums with explicit base types? Or should enums by default be considered as having a `i32` base type unless explicitly specified?

### FSM encoding
Currently, FSM conversion is the only user of the `hw` enum type. In this conversion , we also have explicit awareness of where our state register is, and how we might want the synthesis tool to infer our state machine. FSM encoding attributes are generally supported across different tools ([vivado](https://docs.xilinx.com/r/en-US/ug901-vivado-synthesis/FSM_ENCODING), [quartus](https://www.intel.com/content/www/us/en/programmable/quartushelp/17.0/hdl/vlog/vlog_file_dir_syn_encoding.htm)) and it would be due diligence to consider whether such FSM encoding attributes are an inherent part of an enum type or if it is specific to the site which uses the enum type.

If part of the enum type, there could be 'smarts' which determine that some using ops (like `sv.reg`) needs to be emitted with an fsm encoding attribute:
```mlir
hw.typedecl @myEnum : !hw.enum['onehot']
%state_reg = sv.reg : !hw.enum
// emits as
typedef enum {A, B, C} myEnum_t;
(* fsm_encoding = "one_hot" *) myEnum_t state_reg ;
```

If not, the attribute could be attached directly to the using op, possibly as an attribute of the `fsm` dialect;
```mlir
hw.typedecl @myEnum : !hw.enum
%state_reg = sv.reg : !hw.enum attributes {fsm.encoding = 'onehot'}
```
Which is lowered to an appropriate SV attribute based on the target tooling:
```mlir
hw.typedecl @myEnum : !hw.enum
// circt-opt --lower-fsm-encodings="target=quartus"
%state_reg = sv.reg svattrs [#sv.attribute<"syn_encoding" = "one-hot">] : !hw.enum