bfu_ua_display: Add Ukrainian text rendering library

[BrainFromUkraine]

Add bfu_ua_display package for rendering Ukrainian text on MicroPython displays.

Features:

• Full Ukrainian alphabet support (33 letters)
• 5x7 bitmap font optimized for ESP32
• Works with any display supporting pixel() method
• Tested with SSD1306 OLED displays

Package provides ua_text, ua_text_center, and ua_text_scaled functions.

[Josverl]

Дякую for the contribution.

A few initial comments:
With regards to location I think it should be in the python-ecosys/ folder as it is not part of the MicroPython firmware.
That would still allow it to be directly used by custom firmware.

Also on a first look the PR appears to be created using AI.
while the PR template in this repo does not (yet) explicitly ask this question, the contributor guidelines still apply.
I kindly ask you to add that to the initial PR comment to clarify that.

For more information, consult the MicroPython Generative AI Policy:
https://github.com/micropython/micropython/wiki/ContributorGuidelines#generative-ai-policy

[BrainFromUkraine]

Thank you for the review and feedback.

I've moved the package from micropython/bfu_ua_display to python-ecosys/bfu_ua_display as requested.

All related files were relocated while keeping the public API and functionality unchanged. All formatting, linting, and CI checks are now passing successfully.

I also want to clarify that AI tools were used during development and documentation assistance for this contribution, while the implementation, testing, fixes, and final review were performed manually.

Thanks again for the guidance and review.

[Josverl]

Thanks for clarifying.

Have you considered an optional framebuffer fast path for framebuffer-backed drivers?

Right now rendering is per-glyph/per-pixel via pixel() (and fill_rect() for scaled text), which is nicely portable.
However on common ESP32 display stacks a framebuf/blit path could reduce Python call overhead and make scaled or repeated text rendering significantly faster while keeping the existing pixel() fallback.

[BrainFromUkraine]

Thanks for the suggestion.

Yes, I have considered framebuffer-backed rendering paths as a possible future optimization, especially for ESP32 display stacks using framebuf/blit operations.

The current implementation intentionally prioritizes portability and compatibility across different MicroPython display drivers by relying on the generic pixel() fallback path.

I agree that an optional framebuffer/blit accelerated path could significantly reduce Python call overhead and improve rendering performance for scaled or repeated text rendering.

I’ll definitely explore this direction further while keeping compatibility with existing drivers.