Fees module refactor

[xlc]

Closes #1993

[gavofyork]

why is this reserve?

[gavofyork]

I think the ChargeFee module confuses things in general as it presupposes that Substrate actually has a cohesive and uniform notion of fee. As I mentioned in the issue, it doesn't - economic protections against spam are implemented in numerous ways, only one of which is a straight fee. Reserve and refund doesn't work well beyond the simple assumptions made here (e.g., governance modules make reservations and issue potential refunds that span multiple blocks).

All in all, I would propose to revert the fees module entirely (it was merged without my consent in the first place) and instead introduce a number of ZCAs in any existing modules that do things that you'd want to catch and potentially handle differently. This could include, e.g. Balance module making a new account or transfer charge. There can then be a fees module introduced which can be hooked into all of these events without compromising the performance or API hygiene of the main SRML modules.

[xlc]

@gavofyork I have removed the ChargeFee trait and only keep the make transaction payment functionality in fees module.
I still want to keep fees module for TransactionBaseFee and TransactionByteFee. Previously they belongs to balances module which I don't think it is the most sensible place.

[gavofyork]

#2028 is the way things need to go.

This removes all the fees stuff, replacing ChargeFee with MakePayment. I generally agree that it's not a great fit to have the tx byte/base fee in balances, but I'm also not convinced that setting up a whole other module for it is sensible either. In any case, you can just make an impl of MakePayment for the fees module and use that if you'd prefer to handle fees that way and you'll not take a performance hit.

With all the abstractions I introduce in #2028, you should still be able to do everything you need, including a fairly holistic fees amalgamation module.