add _Bootscreen.h and _Statusscreen.h

[ellensp]

Marlin Documentation doesn't document _Bootscreen.h or _Statusscreen.h

I have added boot_status_screen.md and linked it to configuration.html

Related

add SHOW_CUSTOM_BOOTSCREEN support to HD44780 Marlin#26793

[thinkyhead]

For documenting the boot screen and status screen icon I recommend creating a new page that is linked from the relevant configuration options (and links back to them), and tie those together with the Bitmap tools.

Over the longer term the Configuration page may continue to get updates in its current form for a little while longer, so filling it in with the options that are entirely missing would be a good use of our documentation time ahead of the release. I was also planning to fill in the Menu Tree with missing items.

Looking to the future I started to build a new "Settings" section meant to replace the Configuration page. The YAML can contain information about renamed items and version numbers and so on and the options can be grouped into shorter pages and get pages of their own. The single configuration page was always meant as a placeholder anyway, since over the long term we always knew we'd need some version control connected to configuration and usage instructions.

Although I built the existing Settings pages by hand in YAML, it was never intended that they should always be built by hand. I needed to figure out a structure first, and then I can build automation to produce the structure. The structure is kind of verbose at this point, so I need to add a way to represent "this thing has I-J-K-U-V-W flavors" and spit those out in the templates in a prettier form.

Lately I also realized it would be good to leverage the schema.py script (or equivalent in Auto Build Marlin) and generate Jekyll Markdown from the configuration files going back a few versions (even though they may contain old dead links) to accompany (or replace) the current hand-built configuration.md page.

As part of that I will also take the time to generate a basic index, grabbing all the unique #define names from each configuration going back to the beginning and sticking them in a database, just to have an authoritative tool to know when each option first appeared, and then be able to use that in the configuration index.

[ellensp]

Is this acceptable?