Rework display refresh, add M4SK and add ePaper support

[tannewt]

This PR reworks the display refresh mechanics by replacing wait_for_refresh and refresh_soon with refresh. refresh is required for ePaper and not required for regular displays when auto_refresh is True. auto_refresh can be set during execution to prevent intermediate screen updates. This fixes #1691. 4.x code that calls wait_for_refresh and refresh_soon can have it removed for nearly identical behavior. (wait_for_refresh may have caused a slight delay that could be replaced by self-timing using time.monotonic)

This also adds support for ePaper displays through a sister class to Display. It can handle two color and three color displays.

Lastly, Monster M4SK support was added to test the new refresh code. It also parameterizes the filesystem label so that it can be changed from the default CIRCUITPY.

[dhalbert]

Thanks for this massive amount of work!

[tannewt]

Ok, changes are pushed. I'm still thinking over the ePaper refresh API. I kinda think the return of True/False is too silent because it's not obvious something is wrong.

[dhalbert]

Still also thinking about the refresh() calls, especially for ePaper. For a really long refresh cycle like ePaper, maybe the old refresh_soon() makes sense. But could call it schedule_refresh(), or refresh_needed(), or similar. There could also be a call seconds_until_refresh() that would return how much more time there is, and maybe even a 'refresh_done` property after that.

I'm thinking about some kind of use case where you might, say, light up an LED to indicate a refresh is on the way, an then turn it off when it's done. But maybe that's not real.

[deshipu]

What is the reasoning here behind rising an exception rather than just doing nothing? It forces us to repeat that check for pin everywhere (or catch the exception). Is there a use case where that exception is useful?

[tannewt]

An ePaper display driver may need to detect whether a reset worked because the only way to exit a power down is to reset. Without it, the drivers must leave it on. (The monochrome featherwing needs it.)

[tannewt]

@dhalbert The danger of a refresh_soon or similar is that you may change what is on the screen after the call but before the refresh occurs.

I already added a time_to_refresh property to access how much longer to wait in the cycle. With it, someone can either sleep or do a loop while waiting.

[dhalbert]

This is OK by me now. Thanks!

[tannewt]

I'm going to merge this. @deshipu let me know if you'd like me to follow up with any more changes.