Enum typename considering name in enumeratedValues

[luojia65]

svd2rust has a good mechanism to parse enumeratedValues into Rust enums. However, current code would pick name of the first field the enum resides, and use pub type to re-export it into other names.

SVD files provide name field in enumeratedValues, this commit make use of them to name the Rust enums it generated. After this commit, more information of SVD file is considered in output pac crate. Users may also discover a significant drop in amount of types, which will speed up rustdoc generation and crate compilation.

Before this pull request:


After this pull request:

Note that INTERRUPT_ENABLE_A comes from enumeration name InterruptEnable, but not register name interrupt_enable. 

SVD file for this example:

```xml fifo_error_enable Transmit or receive FIFO error interrupt enable 29 29 true InterruptEnable enable Enable interrupt 1 disable Disable interrupt 0 arbitrate_lost_enable Arbitration lost interrupt enable 28 28 true not_acknowledged_enable Not-acknowledged response interrupt enable 27 27 true ```

[rust-highfive]

r? @Emilgardis

(rust-highfive has picked a reviewer for you, use r? to override)

[burrbull]

Some of enums can be exported from other registers/peripherals (read modules)

[luojia65]

Looks like MSRV 1.51.0 does not support new style format macro: format!("{variable}")

[Emilgardis]

Looks like MSRV 1.51.0 does not support new style format macro: format!("{variable}")

it was added in 1.58.0

[Emilgardis]

im not sure I like this change as it currently stands, it is imo less clear what is happening in the docs

[luojia65]

There are register spec type parameters in BitWriters and FieldWriters, resulting in that write proxies cannot be re-exported properly; I can't apply enum names directly for it would result in conflict (writes with different constant values). Any good opinion?

[burrbull]

cannot be re-exported properly

and should not be

I like idea to use enumaratedValues name for enums, but not for readers and writers.

[burrbull]

Could you move ConstantCase, docs and other code style changes in separate PR? Possibly it makes sense to collect all case related traits in 1 ToCase.

[luojia65]

I'll try to split this pull request, thanks! ;)