in teamgen, make rating ranges bounds of alts and team players consistent

[glbert-does]

currently, our strategy for putting players into teams versus making them play as alt is as follows:

1. create a list of players, and a list of alts (i.e. players who want to be alts).
2. make boards from players, get rating bounds.
3. calculate the number of teams you want.
4. for each board, sort players and remove (number of players - number of teams we want) of bottom ones from the list, add them to the alts list.
5. make boards from alts, get rating bounds.

(source)

since we make the boards for team players and alts separately, this will very often lead to board splits that are inconsistent between the two.

an alternative strategy could be as follows:

1. create a list of players; and an empty list of alts.
2. make boards from players, get rating bounds, use them for both alts and players.
3. calculate number of teams you want.
4. check if there is a board that has fewer players with preference not alt than the number of teams you want.
5. if necessary, decrease the number of teams accordingly.
6. step 4 from the last strategy.

this has the disadvantage of ending up with fewer teams. additionally, the inconsistencies are usually not very large, and some inconsistencies will exist due to players signing up after teamgen anyway. thus, the mods are currently not certain they want this, and want to ponder it for a season or two. i have added this issue more as a reminder of how all of it works, and the alternative strategy we cooked up. i will label it deferred. also, i will assign it to myself, so nobody works on it.

[glbert-does]

another problem with the current algorithm is that it can lead to counterintuitive situations, where a player initially gets pushed into the alt pool from board n in step 4, but then moves to board n +/- 1 during step 5. but on board n +/-1 there are team players who are less deserving of the team spot, so you should actually probably switch them.
still not sure whether that is a large enough problem to justify a different algorithm.