Matrix diagrams and readmes for 60% keyboards

[dunk2k]

Description

for multi-layout 60% keyboards:

• include/append matrix_diagram.md
• add image to readme.md, where none exists

Types of Changes

• Core
• Bugfix
• New feature
• Enhancement/optimization
• Keyboard (addition or update)
• Keymap/layout (addition or update)
• Documentation

Issues Fixed or Closed by This PR

• n/a

Checklist

• My code follows the code style of this project: C, Python
• I have read the PR Checklist document and have made the appropriate changes.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• I have tested the changes and verified that they work and don't break anything (as well as I can manage).

[tzarc]

Having now just seen this, I'm curious why you chose to start documenting this stuff? Did someone on the team ask for it?

I can appreciate the amount of work put into this PR, but given that the long-term direction is to remove as many non-data-driven files as possible, such as readme.md files, I'm not sure we'd want to entertain the addition of more static files.

We're in the (long) process of working out how we deal with layout variations without extrapolating every single combination to a separate LAYOUT_xxx_yyy_zzz macro, so whilst I can see some alignment with that direction I'm curious how/why you think this documentation should be included given the data-driven stance..

[dunk2k]

@tzarc
Thank you for response.
Information in this PR is designed to benefit intermediate (skilled) QMK users who have or are planning to purchase one of the included 60% multi layout boards and wanting to compile, correctly, firmware to their chosen layout.

QMK Collaborators are more than welcome to close this PR if it's genuinely not going be merged, i.e. more "bloat".

Also, I'd like to remind QMK collaborators I have a concept drafted that aims to provide solution to working out how we deal with layout variations without extrapolating every single combination to a separate macro, to which I'm more than happy to share.
Such as solution would negate matrix-diagrams whilst still allowing uses to tailor their firmware to desired/customised layout