[Bugfix] Entering image entropy via long click raises PIL Exception

[kdmukai]

fixes #450

The problem

Prior to this PR, the frame is None check did not affect later attempts to paste that frame into the Renderer upon final image click.

Note: When the camera first starts up, it can initially return frame == None for a few cycles.

If the user enters image entropy (Tools -> New seed) via a long click (click-and-hold), they enter a race condition with the camera: will the camera return a valid frame before the long click repeat triggers the final image logic?

Resolution

This PR:

• reorganizes the if checks in the loop
• adds stricter handling when frame is None
  • adds a very short time.sleep() to give the camera more time to warm up.

Misc

• Slightly more efficient BACK condition to exit the loop (no point in drawing the next preview frame if we're canceling).
• Minor edit to preserve newer preview frames after max_entropy_frames has been reached; now cycles older frames out in order to keep writing the new preview frames. No discernible impact on performance, though I didn't attempt to measure before/after framerate.

[jdlcdl]

as of 91b0206, which is just one commit ahead of Nicks merges last night (2244509),
and assuming that cleanup of imports (Keyboard, TextEntryDisplay, BaseTopNavScreen, FormattedAddress, and QR) is just tidying of unused imports...

ACK tested on raspi-os and on seedsigner-os.

The long press was religiously causing this exception, at least all the way back to 0.5.1-EXP, and a short press was avoiding it. Now, a long press will NOT raise any exception... but I know I pressed long because the captured frame is the next step.

[newtonick]

ACK and tested