Reduce gas costs for the tez wrapper

[gkaracha]

#269 reduces the gas costs of the tez wrapper significantly (data from #269 (comment)):

Gas costs	a8ffcd6	0d1e056	Diff
tezWrapper%deposit	13490	7373	-6117
tezWrapper%withdraw	14410	9758	-4652
tezWrapper%set_delegate	12880	8293	-4587
tezWrapper%transfer	12609	12610	1
tezWrapper%update_operators	4053	4054	1

However, tezWrapper%transfer is the entrypoint most commonly used by Checker and its gas costs are still pretty high. In general, several Checker entrypoints become significantly more expensive when Checker has to go through the tez wrapper (data from #269 (comment)):

Gas costs	a8ffcd6	0d1e056	Diff
checker%create_burrow	6915	22059	15144
checker%deactivate_burrow	11279	23153	11874
checker%withdraw_collateral	11133	22794	11661
checker%deposit_collateral	8901	19760	10859
checker%activate_burrow	8921	19575	10654
checker%set_burrow_delegate	9836	18084	8248

We should investigate ways to reduce these costs as much as possible, lest interacting with burrows becomes too unattractive.

[gkaracha]

Some more thoughts on this:

One of the ways in which #269 reduces the gas costs for calling the tez wrapper's entrypoints is by avoiding indirect calls when a vault has already been originated. However, this makes the average case cheaper, but not the first time someone interacts with their tez-wrapper account (or a burrow does, for that matter). This for example means that checker%create_burrow might always be a little expensive to call, since it needs to originate a new burrow contract and a new vault needs to be originated for that burrow, to hold its collateral. However, for most of the entrypoints I expect the average call to be cheaper than the first call. Extending our end-to-end tests might give us more information about this.

Another thing I am wondering about is what gas cost would be acceptable for entrypoints such as checker%deposit_collateral or checker%withdraw_collateral.

[gkaracha]

Given that 20K gas is acceptable (especially for the more recent protocols), I'd say that this issue is not necessary for v2; let's deprioritize it.