Fix hurry ahead bug + Performance Possible Moves

[YoEnte]

Description

Performance Possible Moves:
Some team made the discovery that the possible moves are extremly slow when handling cards (due to permutations)
-> made a much faster perform move which still generates the same moves (tested with eq() method)
-> kept old possible moves but renamed as reference and if somebody still wants to use it

Hurry Ahead Bug:
On some rare and weird occasions there where possible hurry ahead moves into goal violating the rules engine
-> added small and dirty fix
-> fix in rules engine always broke some other piece of code, therefore the small edge case fix

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

How Has This Been Tested?

Old and newly added tests
Via playing HUI

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes

[maxblan]

This should target_position == 64 && player.carrots > 10 && player.salads > 0, right?
The documentation writes the following:

Das Zielfeld darf nur betreten werden, wenn der Spieler höchstens zehn Karotten und keinen Salat besitzt.

I'm currently not 100% sure, but is the index of the goal not at 65? At least the constants.rs says so. Please verify.
Put these numbers in the constants.rs.

[YoEnte]

it is 64, the index starts at 0, so we got the 65 in the constants... I used it like in hare.rs:72