Return early when fees/balances/values are zero

[shawntabrizi]

Fixes #4402

This PR adds a simple check before relevant balances functions that the "action to be performed" would result in a change.

For example: the function can_slash would normally query the free balance of a user and do a comparison function. However, if can_slash has value.is_zero(), we can simply return true without doing a storage read.

Further, a function like set_lock used to write zero amount locks, which we now skip. Same with add_vesting_schedule.

Ultimately, this PR also catches situations where some external logic, like the fee system, would try to do some action into the balances module with value zero. This may trigger unexpected side effects like emitting a ReapedAccount event when nothing changed in the system.

Please do not treat this PR as insubstantial. Would really want a second pair of eyes to confirm I have not broken any assumptions.

[shawntabrizi]

One side effect of this PR is that a transfer of zero just returns early.

Before, a transfer of zero would additionally charge a fee of T::CreationFee or T::TransferFee on top of the existing fee system.

Now, if the transfer is zero, no logic is run and these additional fees are skipped. A user would still pay the normal transaction fee calculated with the transaction_payment module.

This all makes sense to me, but introduces a new behavior.

[shawntabrizi]

It also means a transfer of 0 emits no Balances events.

[gavofyork]

looks fine except for the comment. i would add notes into the docs of each function explaining that when amount is zero, the function is strictly a no-op.