Fixing future-current transactions clash

[tomusdrw]

1. Because TransactionSet wasn't handling conflicts on it's own there was a possibility that we will endup with by_priority.len() != by_address.len().
2. The situation could happen when one of the clashing transactions was inserted to future, and later there was same transaction that was inserted to current (we would end up with same (sender,nonce) in both current and future)
3. Later when transactions are moved between future and current we could accidentally end up with situation from point 1.
4. Situation 1. is not crashing the system until we call enforce_limit which would detect the inconsistency.

Fixes #801