anchor.diff:  If one or more `variableNameInclude` properties are specified, not all planning variables will be swapped, but only those specified.
   For example for course scheduling, specifying only `variableNameInclude` room will make it only swap room, not period.
   
  +This move selector only supports <<cacheType,phase or solver caching>> if it doesn't apply on any <<chainedPlanningVariable,chained>> variables.
   
   [[pillarChangeMoveSelector]]
   === pillarChangeMoveSelector
  
positive.code: 
  There can be certain moves that you don't want to select, because:
  
  * The move is pointless and would only waste CPU time. For example, swapping two lectures of the same course will result in the same score and the same schedule because all lectures of one course are interchangeable (same teacher, same students, same topic).
  * Doing the move would break <<buildInHardConstraint,a built-in hard constraint>>, so the solution would be infeasible but the score function doesn't check built-in hard constraints (for performance gain). For example, don't change a gym lecture to a room which is not a gym room.
  +
  [NOTE]
  ====
  
negative.code: 
  image::MoveAndNeighborhoodSelection/swapMove.png[align="center"]
  
  Although a `SwapMove` on a single variable is essentially just two ``ChangeMove``s,
  it's often the winning step in cases that the first of the two ``ChangeMove``s would not win
  because it leaves the solution in a state with broken hard constraints.
  For example: swapping the room of two lectures doesn't bring the solution in a intermediate state where both lectures are in the same room which breaks a hard constraint.
  
  Simplest configuration:
  