Fix spend allowance overloading

[pedrovalido]

This pull request addresses C-1 of Macro audit report

[0xcuriousapple]

Fuji contracts allow users to increase/decrease their withdrawal allowance per operator, per receiver through various methods of vault permissions.

fuji-v2/packages/protocol/src/vaults/VaultPermissions.sol

Lines 94 to 108 in efed334

	function increaseWithdrawAllowance(
	address operator,
	address receiver,
	uint256 byAmount
	)
	public
	override
	returns (bool)
	{
	address owner = msg.sender;
	_setWithdrawAllowance(
	owner, operator, receiver, _withdrawAllowance[owner][operator][receiver] + byAmount
	);
	return true;
	}

Hence it's not always given that receiver == operator
Which contradicts this PR

If an allowance is set for a different receiver than the operator, this pr would always spend the allowance for the same operator only.
Either consider restricting operator= receiver only in all allowance methods or refractor this fix to accommodate operator!=receiver case.
One way of doing the latter is overriding transferFrom method directly and using _spendWithdrawAllowance in place of _spendAllowance
https://github.com/OpenZeppelin/openzeppelin-contracts/blob/1642b6639b93e3b97be163d49827e1f56b81ca11/contracts/token/ERC20/ERC20.sol#L160

owner is from
spender is operator
to is receiver
amount needs to be converted to assets

[0xdcota]

There is three ways to modify the '_withdrawAllowance` state defined in the VaultPermissions contract:

1. The ERC20 approve method, required by EIP20, that we override at the BaseVault level. Approve assumes operator = receiver because we have no option. You cannot change the approve method signature and we don't want to have a "dual" approval system. We need to force all approvals to be handled by '_withdrawAllowance` state defined in the VaultPermissions contract.
2. The ERC20 implementation from openzeppelin, has the increaseAllowance or decreaseAllowance which we override at the BaseVault so that, again, there is no "dual" approval system. Since the signature is already defined we then have to assume operator = receiver. If there was a way to delete methods from a parent contract we would just delete these two. They are not official part of the EIP20.
3. The VaultPermissions contract has method increaseWithdrawAllowance or decreaseWithdrawAllowance which includes the parameter sperately for operator and receiver. This is what we want users to "default".

I hope this clarifies. In the mean time I did some small refactors, including to consider the msg.sender in transferFrom as the "operator". Refer to changes in #536

[0xcuriousapple]

Next PR Made to resolve issues of this PR: #536