MarshallerWriteContext.objectMarshallingStrategyStore contains an unpredictable list of ObjectMarshallingStrategy objects which can break Variable unmarshalling (wrt backwards compatibility)

The reason that this is a minor bug is that the user can always fix this by putting the proper ObjectMarshallingStrategy instance into the environment passed to the object doing the unmarshaller.

The idea behind this bug is that we want to make unmarshalling as "unconditional" as possible so that it will always succeed.

• Currently we write the index of a strategy array when serializing. That's no problem if the instance/code deserializing the information is the same as the instance/code serializing the information.
• However, if the serialized information is deserialized by different code[0] than the code that serialized it, it's possible that the strategy array has a different order. Remember, (j)BPM processes can sometimes last years!!

The following code AbstractProcessInstanceMarshaller is where the bug is (see second comment):

stream.writeInt(notNullValues.size());
for (String key : keys) {
    Object object = variables.get(key); 
    if(object != null){
        stream.writeUTF(key);
        // Next 2 lines: we store the _index_ of the ObjectMarshallingStrategy object in the stream
        int index = context.objectMarshallingStrategyStore.getStrategy(object);
        stream.writeInt(index);
        ObjectMarshallingStrategy strategy = context.objectMarshallingStrategyStore.getStrategy(index);
        // This clause is also redundant because .accept(...) already done in objectMarshallingStrategyStore.getStrategy(...)
        if(strategy.accept(object)){
            strategy.write(stream, object);
        }
    }
    
}