Added business value

Low. It's only about how MultiField nodes look in JCR view - whether they are named consistently. Does not affect functionality.

Current situation

Once MGNLUI-6190 / MGNLUI-6253 is integrated, we'll allow resolving multi-field nodes that do not follow the naming convention strictly. However, such nodes retain their inconsistent names.

E.g. 

multi:
  0: 
    field: 0_value
  00: 
    field: 00_value
  multi:
    field: someText_value
  multi1:
    field: someText1_value
  something1: 
    field: someText1_value
  someText1_de: 
    field: someText1_de_value

would, after resaving, turn into

multi:
  0: 
    field: 0_value
  1: 
    field: 00_value
  multi2:
    field: someText_value
  multi3:
    field: someText1_value
  something4: 
    field: someText1_value
  someText1_de: #stays ignored b/c of locale suffix that will cause the node not to be resolved
    field: someText1_de_value

So the prefixes stay empty or whatever they were before, and the numbers get updated.
The implementation reuses whatever prefix it finds via regex when handling a node. This means inconsistent prefixes stay inconsistent.

Desired situation

• Either we will rename the node after resolving right away since we detect its name is bad (this would be a change outside of OrderHandler, and not sure if it's possible)
• or the order handler will have to know the MultiField's name so it can stop guessing the prefix and replace whatever is there.
   
  Or we won't care about it. It's only a question of looks in the JCR browser.