Fix onchain fees lookup query

[evansmj]

issue #6800

Grouping by update_count resulted in a crash due to a bad arithmetic assert in recorder.c line 365 calculating negative fees caused by the returned rows not being consolidated. This removes that update_count grouping and adds tests for single and dual funded channels.

---

Update

update_count is just the count of the records for a tx. To calculate onchain fees
for an account we must sum all credits vs debits. We don't need to GROUP BY update_count
nor ORDER BY update_count since it is just a running index of updates to this tx, so it can be removed.

Previously...
Postgres was not happy with not having update_count in the GROUP BY if it was used in ORDER BY.
The two pull requests below added update_count to this query for postgres:
#6141
#6128

However that resulted in a bad query result in certain situations as referenced in [issue #6800 (https://github.com//issues/6800)

the bad query resulted in something like this:

row  txid  credit  debit
1    blob  1000167000  0
2    blob  0  1000167000

which results in a failed assert due to bad arithmetic (0 - 1000167000 = negative number for a fee):

		ok = amount_msat_sub(&sum->fees_paid, sum->fees_paid, amt);
		assert(ok);

and would runtime crash bookkeeper inspect().

now removing update_count (what this pr originally did) from GROUP BY (but leaving it in ORDER BY) results in something like this:

row  txid  credit  debit
1    blob 1000167000 1000167000

and works for sqlite3 which is less strict on the sql standard. However the postgres tests were failing for the above reason.

Instead of adding update_count to the SELECT column, I remove it from this query entirely. Based on this, I don't believe we need it.

[cdecker]

ACK 7c1f26c