chaintopology: better feerate targets differentiation

We kept track of an URGENT, a NORMAL, and a SLOW feerate. They were used
for opening (NORMAL), mutual (NORMAL), UNILATERAL (URGENT) transactions
as well as minimum and maximum estimations, and onchain resolution.

We now keep track of more fine-grained feerates:
- `opening` used for funding and also misc transactions
- `mutual_close` used for the mutual close transaction
- `unilateral_close` used for unilateral close (commitment transactions)
- `delayed_to_us` used for resolving our output from our unilateral close
- `htlc_resolution` used for resolving onchain HTLCs
- `penalty` used for resolving revoked transactions

We don't modify our requests to our Bitcoin backend, as the next commit
will batch them !

Changelog-deprecated: The "urgent", "slow", and "normal" field of the `feerates` command are now deprecated.
Changelog-added: The fields "opening", "mutual_close", "unilateral_close", "delayed_to_us", "htlc_resolution" and "penalty" have been added to the `feerates` command.

wallet/walletrpc.c

@@ -297,8 +297,10 @@ static struct command_result *json_prepare_tx(struct command *cmd,
 	}
 
 	if (!feerate_per_kw) {
+		/* We mainly use `txprepare` for opening transactions, and FEERATE_OPENING
+		 * is kind of the new FEERATE_NORMAL so it fits well `withdraw` too. */
 		result = param_feerate_estimate(cmd, &feerate_per_kw,
-						FEERATE_NORMAL);
+						FEERATE_OPENING);
 		if (result)
 			return result;
 	}