…nvocationUnit`

…owed

…ystem property.

… ExecutingInvocationUnit

Summary:
This solves the problem of particular array values being possibly `ParticularReferenceValue` or `DetailedArrayReferenceValue` based on how they are created. Now the latter is used consistently, also when a method tracked by `ExecutingInvocationUnit` returns a array of references.

Other inconsistencies of how array are handled are still present and not addressed on purpose, since that behavior is present deeply in the PE code. For example, `ExecutingInvocationUnit#createNonParticularValue` still invokes `ValueFactory#createReferenceValue` even if the argument is an array, instead of `createArrayReferenceValue`, resulting in having an `IdentifiedReferenceValue` instead of an `IdentifiedArrayReferenceValue`. This is because values created outside the invocation unit use methods from `BasicValueFactory` and not overriden by the more advanced value factories, which also never end up invoking `ValueFactory#createArrayReferenceValue`. Trying to change this behavior to have consistency would probably be a longer process, so I'm keeping the code as it is.

NB: the updated behavior will result in `ArrayReferenceValue` being created if `ArrayReferenceValueFactory` is used instead of `DetailedArrayValueFactory` and only in the case an array is returned by an executor (since `createValue` actually invokes `createArrayReferenceValue`), this inconsistency does not happen if `DetailedArrayValueFactory` is used with `ExecutingInvocationUnit`.

In general the fix is quite hacky because it relies on `DetailedArrayValueFactory` calling the `referenceValueFactory` from `ParticularValueFactory` directly, since it needs to bypass the behavior of `IdentifiedValueFactory` because of some improper inheritance.