Split ONNXParser from MarabouONNXNetwork in preparation for replacing with C++ implementation

[MatthewDaggitt]

This commit starts to lay the ground work for #727 by extracting the parsing components of MarabouONNXNetwork and MarabouNetwork into two new classes ONNXParser and InputQueryBuilder. These two new classes will in a future PR be directly implemented by the existing ONNXParser.h and NetworkParser.h on the C++ side (the latter to be renamed to InputQueryBuilder at later stage).

In particular, I've also changed ONNXParser.py to be a pure operation, simply adding constraints to an InputQueryBuilder, rather than storing the constraints internally. This will greatly ease the later implementation of support for queries over multiple networks.

I've striven to maximise backwards compatibility as much as possible, and I haven't broken any example code. The only two unavoidable changes were as follows:

1. MarabouONNXNetwork no longer exposes the fields madeGraphEquations, varMap, constantMap, shapeMap.
   This I think is a distinct improvement as these are really internal implementation details of the parser, and have nothing to do with the constraints generated.
2. MarabouONNXNetwork no longer has a shallowCopy method. Instead of calling this method,
   there's a new parameter preserveExistingConstraints in the method readONNX to
   True which has the same effect and is much more semantically meaningful I think!

[wu-haoze]

Another general thought is that we could just create a MarabouCore.InputQuery object at the initialization of InputQueryBuilder(), and directly encode bounds, equations, ReLUs into the InputQuery, as the methods in the InputQueryBuilder() class are called.

This is probably beyond the scope of this PR, but would be necessary when we replace in the C++ ONNX parser later on. Because the C++ ONNX parser will create a marabouCore.InputQuery object.

@MatthewDaggitt Let me know what you think! I'm happy to do this refactoring, while you're working on the C++ ONNX end.

[MatthewDaggitt]

Another general thought is that we could just create a MarabouCore.InputQuery object at the initialization of InputQueryBuilder(), and directly encode bounds, equations, ReLUs into the InputQuery, as the methods in the InputQueryBuilder() class are called.

This is probably beyond the scope of this PR, but would be necessary when we replace in the C++ ONNX parser later on. Because the C++ ONNX parser will create a marabouCore.InputQuery object.

Yes, eventually I think we should be unifying InputQuery and InputQueryBuilder!

[wu-haoze]

Another general thought is that we could just create a MarabouCore.InputQuery object at the initialization of InputQueryBuilder(), and directly encode bounds, equations, ReLUs into the InputQuery, as the methods in the InputQueryBuilder() class are called.
This is probably beyond the scope of this PR, but would be necessary when we replace in the C++ ONNX parser later on. Because the C++ ONNX parser will create a marabouCore.InputQuery object.

Yes, eventually I think we should be unifying InputQuery and InputQueryBuilder!

I think there is a motivation to have an extra layer (InputQueryBuilder) because of the user-friendly python specific methods for adding constraints. But the layer should be made thiner than what it is now..

[MatthewDaggitt]

I think there is a motivation to have an extra layer (InputQueryBuilder) because of the user-friendly python specific methods for adding constraints. But the layer should be made thiner than what it is now..

Yes, okay. I'm definitely planning to unify the C++ and the Python at the InputQueryBuilder layer. After that we can look at it and reassess the situation 👍