Third attempt at refactoring a smoother PIN timeout transition handling.

Previous refactor from fcf09c2 worked for 'Receive Address' but was
annoying to apply to other panels that also needed to handle PIN timeouts
due to the various different changes needed.

The crux of the issue is that some panels need to know if
a PIN request was triggered. This refactor solves the problem
with a new 'PinLockService' factory that represents and stores
current PIN trigger status. It can be in 1 of 3 possible states:
 - idling: No PIN request has happened. Device may need unlocking. This
   is the initial state. It can transit into verifying.
 - verifying: PIN requested from hardware wallet. Passphrase request will
   also transition into this state if enabled. Will transition back to
   idling if correct PIN is entered. If user cancels PIN entry it will
   go into cancelling state.
 - cancelling: Transition from verifying state when user cancels a
   pending PIN request. Transitions back to idling when user goes
   back to WalletList menu.

This commit undoes most of fcf09c2 and 'successRoute' change in 0f4455d.
This commit fixes the following:
 - Increases speed of show next address in 'Receive Address'.
 - Fixes a 'Conflict Application' bug when clicking show
   next address too fast.
 - Handles PIN request transits properly when sending funds.
 - PIN/Passphrase request no longer triggers multiple loads when
   loading wallet.
 - Set PIN panel to go back after an entry only if previous route
   isn't '/lifeboat' or '/device'. Otherwise success notification
   won't show right away after a settings change.