feat: add ERC4626 Tokenized Vault hook

[scorpion9979]

Related Issue

Which issue does this pull request resolve?

Description of changes

Adds a hook for wrapping/unwrapping assets to/from an ERC4626 vault, inspired by #451.

[scorpion9979]

Ideally ERC4626Hook should be defined as an abstract contract, but I wasn't sure what's the desired convention for testing an abstract contract in this repo.

[partylikeits1983]

Overall this PR looks interesting and combining a hook with ERC4626 opens many interesting use cases. However, could you explain the exact use case for when this hook would be used?

[scorpion9979]

Overall this PR looks interesting and combining a hook with ERC4626 opens many interesting use cases. However, could you explain the exact use case for when this hook would be used?

@partylikeits1983 Enabling trading between vault <-> asset with no Uniswap pool slippage or pool liquidity, limited only by the constraints that exist in BaseTokenWrapperHook. One advantage is smart contract composability: enabling depositing/withdrawing from/into ERC4626 vaults via a Uniswap V4 pool interface.

[marktoda]

Ideally ERC4626Hook should be defined as an abstract contract, but I wasn't sure what's the desired convention for testing an abstract contract in this repo.

Why should it be abstract? Typical convention for testing abstract contracts is to make simple test implementations of virtuals and test those!

[scorpion9979]

Ideally ERC4626Hook should be defined as an abstract contract, but I wasn't sure what's the desired convention for testing an abstract contract in this repo.

Why should it be abstract? Typical convention for testing abstract contracts is to make simple test implementations of virtuals and test those!

@marktoda I was torn whether it should be abstract or not from a nitpick standpoint, as ERC4626 is a generic standard rather than a specific implementation like wstETH. That being said, it doesn't contain any virtual functions and any specific contract implementations extending it would only utilize the constructor instantiation, so perhaps it's fine as is.

[partylikeits1983]

LGTM