Create `sent_payable` table

[bertllll]

This new table should eventually replace the pending_payable table. However, don't pay attention to this old table yet. It can stay in awhile which will make the integration more gradual, with the burden of complex changes as small as possible at the very beginning.

The schema of this table should probably consist of these columns:

receiver_address, amount_high_b, amount_low_b, tx_hash, timestamp, gas_price_wei, nonce, status, retried

Possible status variants:

bn12345678 - block number of the mined block
p - pending
r - retry;
f123 - failure with an opcode that can refer to a certain kind of failure (Maybe like f00 - general failure that we cannot interpret better, f01 - pending too long, f02 - transaction disappeared)

Important: Any status starting with f, that is every kind of failure, will be interpreted as a directive for a retry by the payable_scanner!

Possible retried variants:
0 - so far no need to retry
1 - retried

Some thoughts on the implementation:

Every table is always initialized by the DbInitializer class. That means, add a new function for this table that will be called once in the program's entire history. We must add a new method to DbInitializerReal which calls rusqlite code that will be able to generate the new table. It will be using SQL commands (create table sent_payable (<definitions of the colums>) ). We do the same for each table so there is plenty of examples around. Get also some inspiration for writing tests looking at those already written for the other tables.

This kind of modification has always required a DatabaseMigration. I think we can afford to do it even under the current circumstances since it shouldn't be so hard regarding this task. Reach the other files with individual migrations (each has its own file). Create a new one and try to guide yourself through by examination of those other migrations.

Don't forget to change the CURRENT_DATABASE_SCHEMA by one up (maybe it's recommended to start from there before
you get started working on the migration).

You don't need to work on an implementation a brand new DAO object for this table or even go modifying an old one. We'll reuse the old PendingPayableDao but preferably in a different card.