lcd: add optional putarea()/getarea() operations

[protobits]

Summary

This PR adds an optional putarea() operation that can be supported by an LCD. It allows to increase efficiency in transmission when the LCD supports drawing more than one row at a time in a single transaction. The optionality is done by not setting the callback pointer (drivers need not be changed since when a member initializer for a struct is used, the non-initialized members are default initialized, so the CB pointer is zero). On the LCD character driver side, as discussed in #2166, if the LCD does not support putarea(), it defaults to using putrun() for each row.
A getarea() is also supported for completeness.

While this change is complete and tested, I think this opens up the door other improvements that could be made to better expose LCD functionality. For starters:

• putrun() is a particular case of putarea() so we could ideally remove it. But since NX uses LCD api directly (I think this is a very limiting issue), NX code should be changed to use putarea(). An alternative would be to deprecate putrun() and do the change in the future, but now sure how that could work.
• LCD devices most of the time implement an internal "run buffer" which is mostly needed because the LCD may not support doing partial transfers. For example, some LCDs require a full row update. Other monochrome LCDs require to send full byte transfers if some columns (bits) are altered. Furthermore, some LCDs may not support more than one row per transfer. While in the latter case an LCD would simply not implement putarea, if LCDs would support reporting the minimum-maximum transfer size, an LCD would not require an internal buffer (since the application would only perform transfers of the appropriate size). Since most likely the application calling into the LCD will be managing its drawing operations in its own buffer, an LCD consumes extra buffer space unnecessarily.
  • This is however not the case in NX when using LCD: NX assumes the LCD solves this and does not use its own video buffer, it simply sends putruns() on every draw operation (which is also quite inefficient since it does not consider hidden objects, etc). So again such a change would require changes in NX
• LCDs implement very specific functionality which sometimes is useful to access. For example, I have an LCD which I can put into "fast mode" or not. Other functionality could be enabling scrolling, screen inversion, etc. While we could ideally add one callback for each of these (and one ioctl() to the character driver) I think this does not scale well. I think we should support the most basic common operations (maybe some of these are missing right now, such as setting the backlight), it would be useful to add a ioctl() callback to the LCD driver so that when an unimplemented ioctl is received by the character driver, it is simply forwarded to the low level LCD driver.

From the above, I could work on the ioctl() handling. The other two modifications require going into NX which I'm not personally interested in, but maybe someone else does. Of course this would require discussion before considering it. I personally think that (unless there's a good reason) NX should be a userspace application such as X11.

Impact

Add optional operation, does not affect existing drivers.

Testing

With simulated LCD and LVGL

[protobits]

Ok, I applied all changes except the one about LCD framebuffer.