Fixes 866 and 867

Hi,

I have created a new proposal for solving #866 (closed) and #867 (closed).

This proposal is based on my previous two proposals (MR !1377 (closed) and !1380 (closed)), but a bit extended.

Summary:

• !1377 (closed) MR (basically it is doing what Tom proposed in #866 (closed) issue description) it is solving the issue in ValArray test, by removing the assumption that the ValArray object that was used in move operations will be emptied, but it also weakens a bit the test conditions
• !1380 (closed) MR (approved by Tommaso) solves the issue #867 (closed) by providing an explicit implementation for the move constructor and move assignment to avoid the issues with noexcept specifier and default implementation that does not necessarily match the noexcept specifier, which is detected e.g. by clang-6 but remains a bit unclear whether other newer compilers are more flexible or just ignorant which could potentially maybe lead to some unexpected and undesired behaviors

This MR contains both of these previous solutions but it also adds:

• extends ValArray and hence also MatrixArray class with a flag that indicates whether the instance of the ValArray or MatrixArray is used previously in move operations. This indicator is set to true when the instance is used as rValue in move operations. Both of these classes now have IsValidObject functions that allow us to check if the object is valid before its usage. Also, in all the functions is added assert that checks that the object is valid. E.g. we will not allow any unary/binary operations if any of the objects involved is not valid. This can prevent bugs of type using objects after the move operations.

• extend the ValArray test that was being weakened by !1377 (closed) solution, i.e., we could not test whether the move constructor was being properly called because we did not have any indication of the move operation in the rValue object. Now we can check with the move validation flag and with the new function IsValidObject.