Next step of #6242

This adds the new election algorithm proposed to be used in staking by w3f, PhragMMS. Research paper here.

• This also revamps the old election implementation to use smart pointers. This makes the code a whole lot easier to maintain.
• Consequently some simplifications were applied to both staking and elections-phragmen.
• This does not alter any runtime logic. The election is not yet enabled anywhere. That will be a follow up that can be monitored individually and I didn't wanted to mix that sensitive PR with this one.
• I have already tested this on remote Kusama and the result looks fine and indeed it is better than seq-phragmen, yet the execution time is very very slow, i.e. a few days ago seq-phragmen with 10 balancing rounds took ~5sec on Kusama, while this took around ~50sec with 2 balancing rounds per candidate (executed in native with TestExternalities backend). This is not unexpected. I put some timings into the code and the main reason why this is slow is balanceing, which runs two iterations per candidate that we pick. In short, the current election (seq-phragmen + balancing) us runing 5-10 balancing rounds now, while this will run staking::validator_count() * N, where I've set N = 2 for now, which is still a damn 800 rounds. This is fine, but we should expect some spikes in CPU usage once it is deployed. I will detail these stuff in the follow up PR.

Some follow ups:

• I'd really like to get https://github.com/paritytech/substrate-debug-kit/tree/master/remote-externalities work seamlessly with substrate but sadly can't happen as of now.
• Use of Rational128 is a target of revision in a follow up, and this struct need to be double checked and fuzzed.
• Benchmarks need to be made from the implementation because we need them for the aforementioned paper.