Split player and role numbers

[MaikRe]

Introduced Changes

This PR splits apart player and role numbers.
This is just the foundational work to split the actual enums etc.
It does not yet enable us to play with other jersey number/role combinations.
However, to keep this PR relatively small the implementation of a mapping from playernumbers to roles for the purpose of penalties will be a separate PR.

ToDo / Known Issues

- [x] Fix players.rs and probably add a roles.rs
- [X] Fix role_assignment.rs according to mapping above
- [X] Fix behavior simulator

After talking with @schmidma the idea is to completely remove the player/role number enum, and make role assignment all dependent on increasing jersey numbers, with the exception of the goalkeeper.
We should rely more on information we receive from the game controller about which robots are in play and use that information to make decisions.
-[ ] How do we deal with the initial setup positions, especially if we pick up a robot after deployment and no longer have time to move all other robots around to other positions if we make the positions jersey number dependent

After some brainstorming the problem and solution are actually quite simple:

• Each playing robot needs a number that matches their jersey such that the game controller, game controller controller, and head referee can identify them by.
• We can assign robots to roles by simply sorting the robots from highest to lowest according to their jersey number and using this to assign roles based on priorities that we define, for example, striker is most important, then left defender then etc.
• The exception is the goal keeper, however, the game controller notifies us of which jersey number the goal keeper is, and this can be used to always assign the goal keeper correctly
• When it comes to the initial setup, the robots can also be sorted by their jersey number, such that the goalkeeper has a fixed walk in position, and all others walk in according to positions that are sorted by ascending jersey number. Benefit: HULKs no longer need to remember where to place robots, they can simply look for the ascending number

This is what @schmidma and I discussed, The main issue we noticed from this is the following:
All robots are placed on the touchlines during the initial phase. For example consider jersey numbers 1,2,3,5,7,9,13.
They are placed starting with 1 where we normally place the goalkeeper, 2, and 3 on the same side, and then wrapping around to the other side 5,7,9,13, such that the 13 stands closest to the goal opposite the goal keeper.
The issue now is that if during the initial phase we last minute decide to remove a single robot, and no longer are able to reposition all others, the initial position hypothesis is off. For example, if we remove the 3 and positions are assigned lowest to highest, it means that the 5 will now think it is in the position of the 3, aka on the opposite side of the field, resulting in immediate flipping.

However, all of this was under the assumptions that the robots sort themselves by jersey number based on robots which have no penalty according to the game controller.

The solution is simply to sort robots according to jersey number based on if they don't have a substitute penalty, i.e. they are one of the playing 7 robots. Thus if last minute a robot is picked up and receives a picked up penalty, it is still considered as one of the 7 playing and the positions do not need to be shifted at all.

Ideas for Next Iterations (Not This PR)

- [ ] Implement a mapping of role numbers to player numbers, so that when checking if for example the striker is penalized the check goes through penalties[mapping[striker number]] and correctly determines if the striker is in fact penalized
- [ ] Deal with robots leaving and entering the field when a substitution occurs, i.e. end a single team message from the robot that has entered the field and update the mapping with it

How to Test

The robots and pepsi can be used the same as before, i.e. pepsi playernumber 35:1 32:2 etc.
Behavior in game should not be different than before.
Other assignments such as 32:1:1, 34:9:2, 35:10 should fail.

[schmidma]

Naming suggestion JerseyNumber and RoleNumber to reduce confusion due to previous naming and usage of the term PlayerNumber?

[schmidma]

Do we actually need the RoleNumber? We should probably discuss that in more detail with a whiteboard. But I can imagine a role assignment that does not need any numbering...

[MaikRe]

Do we actually need the RoleNumber? We should probably discuss that in more detail with a whiteboard. But I can imagine a role assignment that does not need any numbering...

I talked to @h3ndrk at some point about this as well and theoretically no, the roles enum containing numbers RoleNumber::One, Two etc could be entirely replaced by things such as Role::Goalkeeper, Role::DefenderLeft etc. So far I have not implemented it in such a way though because

1. These are technically speaking only the main roles, as switching can still happen later in behavior (suggestion: MainRole::Goalkeeper)
2. How do we make this still usable to the deployer as we either need to make it so we have pepsi playernumber <HardwareID>:<JerseyNumber>:<Role> i.e. pepsi playernumber 42:1:goalkeeper which forces the deployer to have to type a lot more and more precisely, or we keep the numbers in the role assignment 42:1:1 but then have to somehow manually remember which number corresponds to which enum element?

Not sure whats the best here

[MaikRe]

Closed in favor of #1449