resolve crashes when running without display

[TychoVrahe]

This PR resolve crashes when uninitialized display returns null ptr as framebuffer and firmware attempts to render into it.

We will need to run some stages of prodtest of T3W1 running without display and this enables it, but we should probably consider allowing this explicitly via some OTP flag, and implement somewhat more elegant way to shutdown when this is not allowed. however, I consider this out of scope in this PR.

[github-actions]

core UI changes	device test	click test	persistence test
T2T1 Model T	test(screens) main(screens)	test(screens) main(screens)	test(screens) main(screens)
T3B1 Safe 3	test(screens) main(screens)	test(screens) main(screens)	test(screens) main(screens)
T3T1 Safe 5	test(screens) main(screens)	test(screens) main(screens)	test(screens) main(screens)
All	main(screens)

[cepetr]

Am I correct in understanding that T3W1 crashes in the bootloader?

The proposed solution is simple, but I suggest a slightly different approach. It's a bit complicated:

Detecting the Display

• If the display is not detected or present, the display_init() function could return false. Alternatively, we could introduce a dedicated display_detect() function to handle this specific purpose.

Handling Uninitialized Displays

• If the display is not initialized, we should avoid drawing on it. We might ensure this in bootui.c, which serves as an intermediate layer between the bootloader and the Rust UI.

This approach ensures proper handling of cases where the display is unavailable while maintaining a clear separation of responsibilities in the code. I believe we should avoid calling any screen_xxx functions if the display or touch interface is not initialized. Additionally, if display_get_frame_buffer() returns NULL while painting on screen, it should be treated as a fatal error.

[TychoVrahe]

As discussed in person, lets consider this out of scope here. I created an issue for handling this later: #4440