[P1] [Umbrella] Consistent gas metering

[lxfind]

We would like to charge gas in a way that's consistent across the board.
To do so, we should use one global gas_status per transaction, pass it down on every operation, charge according to the same gas table. Move already has such as struct, that contains not only the gas cost for all instructions, but also for various storage operations and etc.
Below are what we need to do:

• First of all, we should have a gas_budget for every transaction, including transfer transactions. This will allow us to also be able to create a gas status using that budget, and also able to check gas balance up-front early. (this will change the wallet/REST API too, cc @arun-koshy @patrickkuo @oxade ) For a batch transaction, instead of having a gas_budget per single transaction, we should just have one budget at the top level. Add gas budget to TransactionData #1133
• Next we construct a gas status upfront, pass it everywhere for gas metering. For each place we are charging, we use the constants from the gas schedule table. Consistent gas metering #1219
• We need to be more accurate when we compute the cost of an object based on its size. Right now, we just look at the data size. But we should also include the metadata size. [Gas Metering] More accurate object size calculation #1249
• We need to keep track of the total storage cost (in Sui) for any object, so that when it's deleted, we give back that amount as rebate. When we are mutating an object, we should also give back rebate by deleting the old object, and re-charge the cost based on the new object. [Gas Metering] Add storage_rebate to Object and introduce gas price #1254
• We need to be able to set gas price, which changes across epochs. There will be two separate gas prices, computation gas price and storage gas price. [Gas Metering] Add storage_rebate to Object and introduce gas price #1254
• We need to come up with relatively reasonable gas constants for each gas parameter, relative to the Move instruction gas units.
• We need to add a flat storage charge on any transaction based on the transaction size, because these transactions will need to be stored, too.
• Gas metering for module verification process (especially around abstract interpretation) [Gas Mechanism] Gas metering for module verification during publish #1476

[patrickkuo]

+1 on lifting gas budget from TransactonKind to TransactionData