add hardware matrix and some fixes for feather-nrf* and doc-gen README

[gen2thomas]

I have manually collected a new "Feature-Matrix" document, but most likely it would be possible to generate it.

This features are available for "doc-gen":

• flags to choose the document type for update/creation
• create machine pages (like before, but will be skipped on errors)
• adjust "Interfaces" table in mcu documents (like before, but will be skipped on errors)
• adjust/add "Pins" table in mcu document (like before, but will be skipped on errors)
• create hardware matrix page as a summary of all mcu pages
• print a summary at the end of all generation processes with:
  • processed/failed documents
  • failed targets
  • orphaned documents

In addition:

• add section "Peripheral and Drivers" for hardware-matrix related features
• adjusted the .gitignore to prevent accidentally add content to PR, created by the test of the page at development time
• improve README.md for doc-gen
• fix/add some content in microcontroller pages
• add pages for "Seeed XIAO ESP32 C3", "Adafruit QT Py ESP32-C3"

Please let me know, what can be improved. E.g. one page each for MCU's which support PWM, BT, WiFi etc. would be more handy?

See #384 for some background

[aykevl]

This PR is really big and difficult to review all at once. Can you maybe split it up a bit?

[aykevl]

There are a bunch of different changes that we may or may not want. Putting them all in one big PR makes it near-impossible to be selective about what goes in.

I see you have a bunch of different stuff put together in this PR:

• Changes to .gitignore. Small, so I don't mind those together with an unrelated PR.
• Refactored doc-gen. Refactoring like this usually involves a lot of changed lines, so should really be done in a separate commit at least to separate from actual changes.
• Unrelated changes to imports/main.go (why? They're fine changes, but only add to the size of the PR).
• A big feature matrix. While this can certainly be useful, I wonder why you're parsing them from the various board .md files instead of generating them at the same time as doc-gen?
• More extensive README in doc-gen. A good idea, and could be part of a doc-gen refactor or improvement PR.
• Loads of seemingly unrelated changes to board files (like renaming links)? They may very well be good changes, but aren't really related to doc-gen fixes so should really be in a separate PR.

So basically what I'm asking is to put a bit more work in separating out the changes so that it becomes easier for reviewers to review the PR.

[gen2thomas]

Hi @aykevl , thanks for (try to) reviewing it and your feedback.

Of course, I can split up the parts, like you suggested. Maybe it is also a good idea to change the target branch to dev for the new PRs.