Create LocatorTest for Locator strategies

All promises in the javadocs of LocationStrategyType should be tested with junit tests. Read also javadoc of ScoreDirector.locateWorkingObject() to understand this new system. Documentation will be added next week (week of 21-NOV).

Suggestions:

• I think it's probably best to create a LocatorTest which creates Locator instances and uses a set of Testdata*Solution instances to test them.
• Create test package org.optaplanner.core.impl.testdata.domain.locator and create a separate hierarchy of TestdataSolution variants there (with and without PlanningId, equals/hashcode override, etc).
• Important: I think that TestdataObject will get a @PlanningId annotation on code soon as more and more new functionality will depend on it, so that's why I think it should be a separate hierarchy.

Minimum requirements:

• Test a successful add, remove and locate of a domain object for each LocationStrategyType (except NONE).
• Test that adding/removing a class instance without a PlanningID annotation does NOT fail fast for LocationStrategyType.NONE but locate() throws an exception.
• Test that adding a class instance without a PlanningID annotation fail fasts for LocationStrategyType.PLANNING_ID_OR_FAIL_FAST
• Test that adding/removing a class instance without a PlanningID annotation does NOT fail fast for LocationStrategyType.PLANNING_ID_OR_NONE but locate() throws an exception.
• Test that adding/removing a class instance with a PlanningID annotation that is null fails fast for LocationStrategyType.PLANNING_ID_OR_NONE.
• Test that a class with 2 @PlanningId annotations for LocationStrategyType.PLANNING_ID_OR_NONE fails fast.
• On all LocationStrategyTypes (including NONE), adding/removing a Long instance should not fail fast. locate() should return the same instance.
• On all LocationStrategyTypes (including NONE), adding/removing a String instance should not fail fast. locate() should return the same instance.
• Adding 2 different instances of the same class with the same PlanningId should fail fast
• What happens for LocationStrategyType.EQUALITY if we add class that doesn't override equals/hashcode? The locate() should fail fast.

Philosophy:

• locate() is only needed for multi-thread features and ProblemFactChanges. So by default, the use of @PlanningId is optional (this also helps for migration). But if it is used, it must be valid. If it is not used, then locate() will fail fast.

Note: locate() == locateWorkingObject().

Feedback on method/type names very welcome. there is still time to change it!