feat(db): add MDBX put-append for fast ordered puts

[hai-rise]

We only want 2 things in life:

1. Flush blocks to disk as fast as possible.
2. Commit write transactions as fast as possible.

This led us to DatabaseProvider::insert_block, which is still using put-upsert instead of put-append for tables with naturally increasing keys (like BlockNumber) in the happy/hot paths. For example:

reth/crates/storage/provider/src/providers/database/provider.rs

Lines 2747 to 2755 in 4ddf3dd

	self.tx.put::<tables::CanonicalHeaders>(block_number, block.hash())?;
	durations_recorder.record_relative(metrics::Action::InsertCanonicalHeaders);
	// Put header with canonical hashes.
	self.tx.put::<tables::Headers<HeaderTy<N>>>(block_number, block.header().clone())?;
	durations_recorder.record_relative(metrics::Action::InsertHeaders);
	self.tx.put::<tables::HeaderTerminalDifficulties>(block_number, ttd.into())?;
	durations_recorder.record_relative(metrics::Action::InsertHeaderTerminalDifficulties);

This PR first adds DbTxMut::append with the optimised implementation for MDBX, and a benchmark to show how put-append is much faster than put-upsert in this scenario:

$ cargo bench -p reth-db --features test-utils --bench put
Benchmarking Put/put: Warming up for 3.0000 s
Put/put                 time:   [138.67 ms 138.76 ms 138.86 ms]

Benchmarking Put/append: Warming up for 3.0000 s
Put/append              time:   [80.353 ms 80.538 ms 80.722 ms]

Actual integration into key paths should be done in separate PRs with proper testing and benchmarks. Some places may be able to simply fall back to put, while others may want to report an error for different handling if the key is unexpectedly not the highest.

[hai-rise]

I wonder if this breaking change is a big deal? If it is, then put vs. put-append should be fine; or maybe count both as put? I did this as cursors do distinguish upsert and append already.