Here we present a draft implementation of the `L2BitcoinDepositor` contract
that acts as an entrypoint of the tBTC direct bridging feature on the given
L2 chain. This contract exposes the `initializeDeposit` function that takes the
deposit data (funding tx, reveal info, original depositor) and relays it to the
`L1BitcoinDepositor` contract using the Wormhole Relayer infrastructure.

Here we present a draft implementation of the `L1BitcoinDepositor` contract
that acts as the central point of the tBTC direct bridging feature on the
L1 Ethereum chain where TBTC minting occurs. This contract exposes the
`receiveWormholeMessages` function that receives a message from
`L2BitcoinDepositor` contract (using the Wormhole Relayer infrastructure),
extracts deposit data from it, and initiates the deposit on the tBTC `Bridge`
side. Moreover, the contract also exposes the `initializeDeposit` function
directly. The goal here is to satisfy future use cases that don't rely on
Wormhole Relayer for cross-chain messaging.

So far, the `_initializeDeposit` accepted `calldata` parameters. This
does not work for integrator contracts that obtain deposit parameters
as `memory` objects (the conversion `memory -> calldata` is not possible).

To overcome this problem, we are changing parameters of `_initializeDeposit`
to be `memory` as well. This is not breaking integrators that receive
deposit parameters as `calldata` because the `calldata -> memory` conversion
is fine.

This will be useful to get TBTC token address directly from the vault
contract.

Here we implement the finalization of the deposit flow. This process
is started on the `L1BitcoinDepositor` side once the tBTC `Bridge` completes
minting of the TBTC token. The process consists of multiple steps:

1. The `L1BitcoinDepositor` marks the given deposit as finalized and determines
   the amount of TBTC minted.
2. The `L1BitcoinDepositor` initiates a Wormhole token transfer. This transfer
   locks minted TBTC on L1 within the Wormhole Token Bridge and unlocks
   Wormhole-wrapped L2 TBTC for the `L2WormholeGateway` contract.
3. The `L2BitcoinDepositor` sends the transfer VAA to `L2BitcoinDepositor`.
4. The `L2BitcoinDepositor` finalizes the transfer by calling the
   `L2WormholeGateway` that redeems Wormhole-wrapped L2 TBTC from the
   Wormhole Token Bridge and uses it to mint canonical L2 TBTC for the
   L2 deposit owner.

Here we adjust the new contracts for deployment:
- We are introducing the `attach*BitcoinDepositor` functions to solve
  the chicken & egg problem that occurs upon deployment
- We are adjusting gas limits for Wormhole to real-world values
- We are getting rid of cross-chain Wormhole refunds that don't work
  for small amounts

Here we add deployment scripts for both `L*BitcoinDepositor` contracts.
We use Base as the reference chain.

We are testing the implementation by deploying it on Base Sepolia chain.
Here are the relevant deployment artifacts.

Such a deposit reveal was tested for Base -> Ethereum and turned out
to be super expensive. It takes ~0,045 ETH so ~150 USD to transfer deposit
data to Ethereum. This is an unacceptable cost. To overcome that problem,
we are abandoning the idea of using Wormhole Relay for that in favor
of our own relay bot implementation. This also makes sense as eventually,
we are aiming towards using gas-less reveals on Base.

The OZ upgrade plugin complains about unsafe upgrade if standard versions of
`IERC20` and `SafeERC20` are used.

We need to make sure only owner can call this function.

It's enough to store the `gasSpent` as `uint96` which allows us to save
one storage slot. Moreover, we are increasing the default value of
`initializeDepositGasOffset` to adhere to real-world gas consumption.