EnemyFreeKickPlay FSM Conversion

[Andrewyx]

Please fill out the following before requesting review on this PR

Description

This PR addresses the EnemyFreeKickPlay redesign in which we transform the existing design utilizing co-routines into the current FSM framework.

NOTE: This PR contains a stopgap redesign of DefensePlayFSM to suit the case of EnemyFreeKickPlayFSM. This PR shares significant similarities with DefensePlayFSM and is planned to be refactored along with DefensePlayFSM in a following PR.

Otherwise same behaviour as DefensePlayFSM, but:

1. Only 1 pass defender allowed to guard enemy kicker (Main Pass Defender)
2. Robots obey standard 0.5m obstacle radius around ball per Free Kick rules, this implementation uses 0.6m to better avoid violation area
3. All redundant pass defenders X meters around the main pass defender are skipped to ensure we do not have duplicate assignments too close to one another (this "skip region" set to a radius of 3m of the Main Pass
4. Introduces new Mid Point defender to guard mid region between the ball and net in cases when large gap exists

Other Changes:

• Uses Suchir's OrValidation from #3123
• Implements new ball_moves_from_rest validation to check when the ball is moved per the RoboCup 0.05m standards.

Testing Done

Pytests have been written to test behaviour. This can be run with ./tbots.py run enemy_free_kick_play_test.py -o -t

~~KNOWN BUGS:~~ FIXED ~~- If the Main Pass Defender switches roles, it may cut through the foul region, this will be most likely fixed in the new dynamic trajectory planner PR #3152~~

Resolved Issues

Resolves #3011, Re-implements #2970

Length Justification and Key Files to Review

This PR is broken up into two PRs, this one focuses on the implementation of the FSM. A future PR will be used to refactor EnemyFreeKickPlayFSM and DefensePlayFSM and abstract away shared functionality.

Review Checklist

It is the reviewers responsibility to also make sure every item here has been covered

• [x] Function & Class comments: All function definitions (usually in the .h file) should have a javadoc style comment at the start of them. For examples, see the functions defined in thunderbots/software/geom. Similarly, all classes should have an associated Javadoc comment explaining the purpose of the class.
• [x] Remove all commented out code
• [x] Remove extra print statements: for example, those just used for testing
• [x] Resolve all TODO's: All TODO (or similar) statements should either be completed or associated with a github issue