Changes related to RC costs

Needs test-tools!69 (merged)

The changes are as follows:

• new budget and state usage values - now they directly reflect memory consumed by operations in byte-hours (persistent state is counted as 5yrs of use duration, state with undefined duration counted as 2.5yrs of use); the change drastically increases cost for operations that build new persistent objects (f.e. new account) in relation to those that only create temporary objects; state use duration is now important factor that shapes cost of some operations (f.e. proposals)
• new budget and exec values - taken from #205 results made on "typical witness hardware"; the budget is short lived (1 hour half-life compared to previous 15 days half-life) and now focuses on live sync execution times rather than replay times; live sync related costs are calculated (like time of authority verification or validation of transaction); the change flattens execution related costs across types of operations (since authority cost is dominant) and reacts much faster on changes in transaction traffic
• new mechanism for computing differential state usage - many costly operations actually only replace existing state rather than allocate new (f.e. when account is updated with new keys without making authority more complex); such situation is now properly handled; also when some operation releases state (f.e. setting 0% vesting route) it is no longer charged as if it was creating state
• mechanism for calculating resource popularity in time window (1 day) is now used to balance how global RC regen is allocated towards resources (previously each pool behaved as if all global regen was to be used on it alone); it should make adding more RC pools in the future much easier (no need for rebalancing); it makes popular resources more costly faster and those less popular cheaper which helps diversify types of operations in high traffic environment (f.e. when high traffic consists mostly of custom_jsons which use history pool, they will become more expensive faster, comments that also use history pool but more heavily consume state can then become cheaper because state pool will be less popular); the average cost difference compensated with 3 times higher cost per unit for each pool (with the exception of new account tokens that are considered "luxury item"); overall RC consumption is slightly smaller but close to previous one
• while RC plugin works on historical operations (since HF20), due to amount of changes that make some past operations too costly for selected accounts (the main reason being much higher cost of creating accounts), the "Accepting transaction... <you did not have enough RC yet accepted>" became too spammy, so it was cut off until after HF26
• removed RC option that looked like it could potentially be source of disagreement about RC between nodes - --rc-compute-historical-rc - as well as internal flags skip_deduct_rc and skip_negative_rc_balance