Docs: Prefer module-specific settings over board configs

[ghost]

EDIT: This pattern would be a good thing to add to the Development docs so others understand how and why things are done this way.

Building on top of #159 and #160, it would be better to remove the board.config["krux"] pattern and instead have the modules themselves define settings that they reference to make decisions, where the default value of a setting could be based on the board.config["type"] or similar non-Krux-specific properties.

This would:

1. Let us clean up board configs in MaixPy so we can remove the krux key and once again match upstream MaixPy's versions
2. Keep board-specific logic very close to where it matters, in the module that uses it
3. Allow users to override particular settings as they see fit and have them persist on microSD

This would also resolve https://github.com/selfcustody/krux/issues/147 nicely.

Using that as an example, if display.py had a DisplaySettings class with an inverted_coordinates property, the default value could be initially set based on if board.config["type"] == 'amigo_tft'. The calling code could then say if settings.display.inverted_coordinates: <do stuff>, and users could go into their Settings to override this if they wanted.

[ghost]

@odudex See my work in https://github.com/selfcustody/krux/pull/164 for examples of the new pattern, particularly thermal.py

[odudex]

@jreesun , looks good! Do you think I should create a setting covering cameras? I think no setting is necessary for them. The way I did cameras are "plug and play". There's nothing to set, neither by user, neither by any hard code. Maixpy already does the job of finding out what camera is being used and the few necessary adjustments are constrained in camera.py file

[ghost]

What you did with cameras makes sense to me! When there's no possible variation, a setting wouldn't apply. I just wanted to make sure you saw this if you decided to start refactoring display or other classes where user preference may apply.

[odudex]

Got it! Yes, I'm watching the changes and will follow the new pattern in case I change something.

[odudex]

Tested your latest code. It seems Maixpy can't handle __dict__

[ghost]

Oi! That's what I get for only testing in the simulator... I'll see what I can do, thanks

[ghost]

@odudex Fixed here: https://github.com/selfcustody/krux/pull/167 Going to merge once tests pass