The extensibility of the VRPProblem should be improved for creating new problem instances

[pfleck]

In order to implement a new VRP problem instance you have to extend the VehicleRoutingProblem because the IProblemInstanceConsumer interface has to be added. This is not desired because only the ProblemInstance should be extended and not the problem itself.

public interface IVRPInstanceConsumer :
  IProblemInstanceConsumer<CVRPData>, IProblemInstanceConsumer<CVRPTWData>,
  IProblemInstanceConsumer<MDCVRPData>, IProblemInstanceConsumer<MDCVRPTWData>,
  IProblemInstanceConsumer<PDPTWData> {
}
	
...
public sealed class VehicleRoutingProblem : ..., IVRPInstanceConsumer {

[pfleck]

r10435

• Removed generic argument of VRPInstanceProvider.
• Removed specific IProblemInstanceConsumer interfaces.
• Added dynamic lookup of compatible interpreter.

[svonolfe]

added static apply methods to VRP operators in r10460

[pfleck]

r10475 made static apply method for Potvin IterativeInsertionCreator public.

[abeham]

Is it possible to define an interpreter in the VRPData so that we don't need the dynamic lookup of the interpreter?

[pfleck]

Replying to abeham:

Is it possible to define an interpreter in the VRPData so that we don't need the dynamic lookup of the interpreter?

This would cause a problem dependent dependency. As the HL.Instances are problem independent, I think this should be avoided.

Besides, this change would probably cause a cyclic dependency too.

[pfleck]

r10651:

• Lookup for appropriate Interpreter now causes an InvalidOperationException if no or more than one interpreter is found.
• Put InterpreterDataType extraction into new method for better readability.

[pfleck]

r10652: Added unit test which loads all available VRP instances to check correct interpreter lookup. (Same approach as QAPLIBInstancesTest)

[abeham]

OK

[pfleck]

r10744: merged r10435, r10460, r10475, r10651,r10652 into stable