EEPROM Refactor

[thinkyhead]

A classic project to refactor the EEPROM. Added to the new Projects Table interface.

Summary: For better code organization, create a Feature class that has EEPROM (and other) hooks. Each feature implements a Feature subclass (e.g., FilamentSensorFeature) containing its data and populating any other needed hooks. The settings.cpp code will then call back to these hooks in each feature to do its work instead of having to know about the data of each feature. Marlin core data that is always stored to EEPROM can also get a Feature subclass.

The second part of this is restructuring the EEPROM storage in a format similar to classic Interchange File Format (IFF) where each feature stores a block of data with a header. The block starts with a 4-letter code (FILS), a version number (0x0001), the data size (0x01E2)), and a checksum, then the data follows. This allows stale data for features that were turned off to be skipped. Features can choose to update an older version of the EEPROM data to the current structure, or just throw it away.

The problem is relatively straightforward, so it's just a matter of moving everything out of settings.cpp methodically over to the new system. The final settings.cpp file will contain a new EEPROM read method that scans through the EEPROM data and just calls back to each feature based on its 4-letter code (a long switch-case with many features represented). The EEPROM write and reset methods will retain any order dependencies, and/or the "settings priority" of each feature can be provided by a Feature callback, allowing features to be read-and-applied or reset-and-applied according to priority order (pref. in a fashion that can optimize at compile-time).

See the Code Refactoring Project for more fun upcoming refactors!