Bugfix/LS24004606/MOVEL Array to Array

[davidepalladino-apuliasoft]

Description

This work fixes the assignment of array to another with MOVEL. For example:

     D ARR_1           S              1  0 DIM(3) INZ(1)
     D ARR_2           S              1  0 DIM(5) INZ(2)
     ...
     C                   MOVEL     ARR_1         ARR_2      

Technical notes

On Jariko this operation caused: Cannot set an array as factor 2 in MOVEL/MOVEL(P) statement. Isn't a impossibility; this case was simply not covered. To achieve the goal of this PR, for movel I have added the case when the source (Factor 2) is an array as well as the target. For more readable and maintenance, I refactored movel by separating the case when Factor 2 is an ArrayType (on movelFactorAsArray) and when is not (movelFactorAsScalar). In this last case, there are no changes that I have made: the logic is like previously except for the utilization of when.

Related to #LS24004606

Checklist:

• If this feature involves RPGLE fixes or improvements, they are well-described in the summary.
• There are tests for this feature.
• RPGLE code used for tests is easily understandable and includes comments that clarify the purpose of this feature.
• The code follows Kotlin conventions (run ./gradlew ktlintCheck).
• The code passes all tests (run ./gradlew check).
• Relevant documentation is included in the docs directory.

[lanarimarco]

I have to trust your implementation because you have mixed refactoring with functional changes, and as I mentioned previously, this makes it difficult for me to understand the modifications.

@benetti-smeup, please review the tests.

[davidepalladino-apuliasoft]

I have to trust your implementation because you have mixed refactoring with functional changes, and as I mentioned previously, this makes it difficult for me to understand the modifications.

@benetti-smeup, please review the tests.

I agree with you but for this circumstance was needed to avoid a big method.
@benetti-smeup For tests, all of there were made and tested on AS400.

[lanarimarco]

I agree with you but for this circumstance is was needed to avoid a big method.

The rules I provided were:

1. A refactor commit
2. Changes

Or

1. Changes
2. A refactor commit

This way, I am able to evaluate the changes more easily. However, I realize that following these rules is not always simple.