Internal experiment: Generate SVDs from internal CSVs in esp-pacs, avoiding internal tools

[playfulFence]

For now, I have no intention to merge this, it's more like "look, this is possible", feel free to experiment with it (I think @bugadani will be happy to do so 😄 )
With a change like this, I'm aiming to
A) centralize the entire process of creating a PAC for new chips in esp-pacs
B) make the toolset for this to be completely written in Rust, previous internal tools were written in Python, required a lot of dancing around venv and "ew" was the most frequent reaction on working with it 😅

The CSV-parsing part entirely is a product of AI development, code might need to get cleaned up, but again, this is a "blueprint" of a potential future change.

Trying it

cargo xtask generate-base-svd \
  --chip esp32h21 \
  --csv-dir /path/to/csv \
  --interrupts /path/to/esp-idf/components/soc/esp32h21/include/soc/interrupts.h \
  --reg-base /path/to/esp-idf/components/soc/esp32h21/register/soc/reg_base.h

--interrupts and --reg-base are required. This allows to reduce the noise without huge ymls that are written based on these idf headers anyway. Register layouts still come from the GDVS CSV pack. That combination already produces a very close "clone" of what we currently get from internal tools for the base SVD.

[burrbull]

What reason of manual text writing instead of svd-encode?

[playfulFence]

Hello!

As I said in the PR description, the parsing section is almost completely written by AI and might need a bit of a cleanup in the near future. But also, to be completely fair and I might be wrong here, feel free to disagree with me, but I’m fine with a bit messy/AI-looking generator code, which will also be used exclusively by the team members (as internal CSVs are confidential), as long as the SVD output is correct, we're unlikely to change that code very often.