Since 8cc20fb, we hash the invoices on Send&Print instead of when posting.

This may result in weird behaviour for instance when we:
- Post INV/1
- Post INV/2
- Post + Send INV/3
- Send INV/2

The hash of INV/2 will depend on INV/3, which is not what we want. This will also look weird in the inalterability report where the first move hashed might be the last move of the sequence and vice-versa.

To fix this, we will now retroactively hash the moves on Send&Print for invoices, and on post for bills. In the previous example, this means that when we hash INV/3, we should first hash INV/1 then INV/2 and then INV/3.

For invoices, if the user does not want to Send&Print the invoice but wants to have a hash, he/she can click on the button to hash the invoice which will also retroactively hash the previous moves.

This retroactive hashing is not sufficient for cases where we have a mix of invoices with different sequence_prefix.

From now on, we will have a hash chain per sequence_prefix instead of per journal. If, for instance, one uses a series such as INV/2024/00001, INV/2024/00002, ..., the sequence_prefix is INV/2024, and therefore we will have one hash chain per year.

This also allows us to get rid of the secure_sequence_id, and the secure_sequence_number, and we can only depend on the sequence_number.

However, we have to keep the secure_sequence_number field for the integrity verification of moves previous to this commit because it defines the order on which the moves were hashed.

We also now show a warning on the Accounting dashboard if the journal has unhashed entries that redirects the user to the moves that need to be hashed.

task-id 3820975

closes odoo/enterprise#59243

Related: odoo/odoo#158823