Don't add SiblingOrder when specialising the first element of an archetype

[VeraPrinsen]

Example of the bug:

flat parent archetype:

CLUSTER
   ELEMENT[id2]
   ELEMENT[id4]

flat child archetype:

CLUSTER
   ELEMENT[id2]
   ELEMENT[id2.1]
   ELEMENT[id4]

Expected differentiated archetype:

CLUSTER
   ELEMENT[id2.1]

What comes out of the differentiator at the moment:

CLUSTER
   after[id2]
   ELEMENT[id2.1]

This gives errors when flattening the archetype, and puts the specialised id2.1 element last instead of at the place of the original id2 element.

Problem was in the 'handleDirectlyAfterSameParentNode' method where the parent id code was found, but because the for loop ended, the method still returned 'false', even though there was a parent node that this specialised element could go right after.

[VeraPrinsen]

In the flattener, specialised nodes will appear after their parent if there is no sibling order attacked to the specialised nodeId

[codecov]

Codecov Report

Attention: Patch coverage is 75.00000% with 2 lines in your changes missing coverage. Please review.

Project coverage is 71.80%. Comparing base (e36d98e) to head (d98ac4f).

Files	Patch %	Lines
...in/java/com/nedap/archie/diff/LCSOrderingDiff.java	75.00%	1 Missing and 1 partial ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##             master     #604      +/-   ##
============================================
- Coverage     71.80%   71.80%   -0.01%     
+ Complexity     6956     6955       -1     
============================================
  Files           663      663              
  Lines         22691    22690       -1     
  Branches       3676     3676              
============================================
- Hits          16294    16292       -2     
  Misses         4664     4664              
- Partials       1733     1734       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.