feat: Implement non-blocking long-press detection logic (Implements Issue #287)

[securesigner]

This PR implements non-blocking logic to distinguish between short and long button presses in the hardware driver. This enhancement is needed for enabling new UI interactions (e.g., "Long Press for Home" or shortcuts) without disrupting the existing input loop.

The changes focus strictly on the HardwareButtons logic to enable the capability, as requested in Issue #287.

Screenshots omitted as this is a backend hardware logic change with no visible UI modifications yet.

This pull request is categorized as a:

• New feature
• Bug fix
• Code refactor
• Documentation
• Other

Checklist

• I’ve run pytest and made sure all unit tests pass before submitting the PR

If you modified or added functionality/workflow, did you add new unit tests?

• No, I’m a fool
• Yes
• N/A

I have tested this PR on the following platforms/os:

• Raspberry Pi OS [Manual Build]
• [SeedSigner OS] on a Pi0/Pi0W board
• Other (GitHub Codespaces / CI Environment)

Note: Keep your changes limited in scope; if you uncover other issues or improvements along the way, ideally submit those as a separate PR. The more complicated the PR the harder to review, test, and merge.

[securesigner]

Reflecting on the discussion in #287: This PR provides the backend driver capability required to implement features like 'Long Press to Go Home' or 'Hold to Confirm'. It creates the KEY_PRESS_LONG event without forcing a specific UI implementation yet, solving the space constraint issues mentioned by @kdmukai by reusing existing buttons.

[kdmukai]

I haven't reviewed the changes yet, but two quick thoughts:

• I would hold on this until there's a PR that builds on this to implement the UX change (e.g. long press the BACK arrow to fully exit a flow). Put another way: I would not be in favor of merging this unless it's going to actually be used.

• Very minor nit: I wouldn't tag this as "fixes [issue num]" as that issue is not a bug report. "Implements" is probably a better word choice. I forget which keywords github pays attention to to auto-close issues. Maybe "resolves [issue num]"? But I think that has to be in the PR description to work.