feat: open position wrapper

[kaze-cow]

Description

Implements the CowEvcOpenPositionWrapper in order to satisfy a usecase for the Euler integration.

Context

Read up on notion

Considerations

• While we call this flow "open positoin wrapper", it could also be used to grow an existing position, or take on a position without buying any Euler tokens (by setting collateralAmount to 0)
• this should be compatible ewith CoW (if two users open opposite positions, for example)

Out of Scope

Every line of code in this PR should be considered in-scope.

Testing Instructions

Follow the test command instructions in the README

We want to make sure:

• the flow works as expected for the established cases of Euler finance.
• there are not security opportunities an arbitrary user on the open internet could take advantage of
• there are not security opportunities that a solver could take advantage that would give access to a significant amount of funds

fixes https://linear.app/cowswap/issue/COW-65/initial-merge-contract-of-cowevcopenpositionwrapper

[fedgiac]

Overall the parameter name and explanation is confusing to me. The permission it needs is more specific than the text suggests.
Same comment in _encodeBatchItemsAfter

Suggested change

	/// @return needsPermit Whether these items require user signature or prior authorization as an operator
	/// @return canUsePermit Whether the returned batch items are intended to be optionally executed in an EVC permit

[kaze-cow]

The permission it needs is more specific than the text suggests.

Hmm, in a general sense, the flag is intended to indicate whether the things returned require some sort of special permissions. The way that those permissions can be obtained varies (either setAccountOperator or EVC.permit), of course, So I thought needsPermit was an overall good . Would needsPermission be better indication of such a thing? I just want to confirm exactly a label that makes sense to both of us before I go in and rename everything again 😆

[kaze-cow]

also I prefer th ecomment as it exists right now. The new comment in your suggestion makes it sound like the authorization from the user is somehow optional, but its not.