Move `sp-npos-elections-solution-type` to `frame-election-provider-support`

[kianenigma]

... and derive MaxEncodedLen for it. Deriving MaxEncodedLen should be rather tricky. The final struct for which we want to derive it looks like this:

pub struct Foo {
  votes1: Vec<T1>,
  votes2: Vec<T2>,
  votes3: Vec<T2>,
  ...
  votes16: Vec<T16>,
}

And while the inner types (T1 to T16) are all bounded, Vec is simply not MaxEncodedLen.

One option would be to try and move all of the Vecs to BoundedVec. I strongly advice against that, mainly because I speculate that we want to re-think generate_npos_solution! macro overall and not generate it at compile-time.

What I recommend instead is to take a simpler approach, and accept that our MaxEncodedLen estimate for this type will be slightly pessimistic for now. We leverage the known fact that T1 < T2 < ... < T16. Also, we leverage the fact that we could know sum{votes1.len(), votes2.len(), ..., votes16.len()} at compile time (hint: this is essentially the same as VoterSnapshotPerBlock ;) ).

So all in all, the macro will be given one bound, named b (either as an expression or a type that is Get<u32>), which is essentially the total number of possible voters that this solution could represent. Then, the MaxEncodedLen will assume that votes16 (or whatever is the maximum) has b items and all the rest are empty.

Of course, this needs to be rethink-ed before this type is efficiently usable in a parachain, but for relay chains it is fine.

[kianenigma]

closed by the linked PR.