Chore(suite): refactor FW check selectors

[Lemonexe]

Description

Refactor selectors for FW authenticity checks, as they became complex, duplicated and with misleading names.
Most notably, soft errors were called skipped errors, even though they display banner, so they're not rly skipped 🙈

Incidentally, fix small issue from #15555 where sentry reports even skipped errors like check-unsupported. The main purpose of 15555 was to report it even when turned off in settings. But thinking about it again, IMO we should report soft reivision check errors too (also didn't before 15555), but exclude the skipped hash check errors.

• bac0120 rename skippedErrors to softErrors, because they were used as such, and decouple skippedErrors
• bbab835 actually use skipped hash check errors in selector to centralize it
• b9357d7 rename error selectors to errorIfEnabled, and split error from them so they can be used for Sentry
• 4394bf5 on the other hand, squash selectors used only locally, IMO they don't add much clarity
• b429b12 introduce another category - errors skipped but still reported to Sentry 🙈
• 266e7f5 add other-error to that category
• 2eea204 cleanup: reorganize scenarios for each errors

You can test other-error by checking out testing branch

Notes

I attempted to standardize variable names as follows:

• we start with the basic definition of any error (of those types). Some of those are:
• skipped error: is not handled at all
  • no modal, not blocking recieve addr, no banner, no sentry
• skipped but reported error:
• soft error: is handled in a non-blocking way
  • no modal, not blocking recieve addr, but will do banner, sentry
• hard error: fully handled, gets the full treatment
  • modal, blocking receive addr, banner, sentry
  • equals "not soft error"

Still, it's not consistent between revision & hash check because they got different requirements:

• revision check only has soft and hard, but no skipped
• hash check has skipped, skipped+reported and hard, but no soft

[Lemonexe]

softHashCheckErrors will be removed in next commits (no need to support that)

[Lemonexe]

useReportRevisionCheck is now much nicer thanks to the new selector that gets error regardless of enabled.
But useReportHashCheck does not use it, as it also needs payload, so I have to do the whole decision process again.
💭 I could create selectHashCheckErrorPayload but sounds like overkill, what do you think?

[Lemonexe]

📝 note: I tried passing just hashCheck to the useEffect, and declaring hashCheckError, hashCheckErrorPayload within the useEffect body.
At first glance it's nicer, as I can early return & avoid the ternaries.
🚫 But hashCheckobj from redux is referentially unstable, so it Sentry fires repeatedly