build-fpga-regmap: namespace generated enum types

[hawkw]

When the build-fpga-regmap code generation emits a Rust enum type for enum fields in FPGA registers, the generated Rust type is named after the name of the register field (after being converted to CamelCase), and emitted in the same top-level generated code module as the register view types.This is all well and good until two different FPGA registers want to have enum fields with the same name, which seems like a fairly reasonable thing for the hardware folks to want to do. When there are two or more enum fields in different registers sharing the same name, the generated Rust types collide and the code no longer compiles.

For instance, the FPGA changes @nathanaelhuffman pushed in 26f4837 added a second enum field named hw_sm, in the nic_raw_status register. This results in generating a type that collides with the seq_raw_status[hw_sm] field. Rather than making Nathanael go back and rename all his register fields, the codegen should properly handle this.

Thus, this commit changes the code generation a bit so that enum field types generated by build-fpga-regmap are now emitted in submodules named after the register containing that field. So, rather than having fmc_sequencer::HwSm as the enum that represents the seq_raw_status[hw_sm] field, we now produce fmc_sequencer::seq_raw_status::HwSm, allowing it to coexist with the new nic_raw_status[hw_sm] field's enum, which lands in fmc_sequencer::nic_raw_status::HwSm.

This requires a small change to cosmo_seq to get the enum types from the correct places. Thus far, I think the cosmo_seq task is the only Hubris task that touches FPGA registers with enums.

This is required for #2390