This makes the "new transactions above this line" concept more coherent.
We now save the last known transaction in the model, which is only
loaded in the GUI version of Pay.
Then if new transactions are found (or created) in the background runner
then the next time we start Pay, they will be marked as such.
This also adds some logic to the UI to detect that the history is
actually the visible component right now, and if it is then we start
an 80 second timer that, after expiring, will reset the last seen to
the most recent transaction.
We already check for duplicate running, instead of showing the non
functional UI, this changes to instead wait for the lock to become free
after which we run the 'init' and load all the data.
This avoids people approving when they intent do just open the details
screen. User tests showed that the confusion of hitting the checkbox
when the details screen was aimed for was masking the actual action
taken, making it dangerous to leave it larger.
This shows more details, like the target address.
This also made the screen able to handle multiple outputs in a payment,
though that is a bit tricky with regards to which values we allow
editing.
The crazy animation caused it to show a little at the top on hide, so
now we move it further off screen to avoid that.
Additionally this removes the semicolons from these pages where
applicable. It's cleaner without them then sometimes there sometimes not
there.
When the user manually pastes an address, this would also be a payment
object and that makes no sense to save. So make it configurable
and have external payment protocols (i.e. 3rd party invoices) as well as
repeated payments get saved.
This also removes any associated repeated payment objects and a
lingering deleteLater which becamse obsolete some time ago when we moved
over to wrapping the wallet in a shared pointer instead.
tomFlowee