[Fix] Mapping issues between a dropdown with multiple answers and it's form destination

[jdurand-teclib]

• I have performed a self-review of my code.
• I have added tests (when available) that prove my fix is effective or that my feature works.
• I have updated the CHANGELOG with a short functional description of the fix or new feature.
• This change requires a documentation update.

Description

• It fixes !46462
• Here is a brief description of what this PR does
  • Add distinct treatment for multiple dropdown field type. It was treated like a classical dropdown and it's answer was casted as an int instead of an array
  • When formating raw answers, read $answer['items_id'] in case of a multiple dropdown containing several glpi items to avoid display issued in the items names.

Important

Change of behavior: As a form already has default values, deleting pre-written default answer to a question when filling the form was actually replacing it by field's default value, whereas it would be more logical to imagine that the user actually wanted to leave the form blank.
Logic is consistent the other way around with a default value in the field but not in the form, as the user has no idea of the field configuration, he would find himself with values on a field he left blank.
The previous behavior was not documented on gitbook.

[Rom1-B]

Pre-existing bug in this loop, not introduced here, but worth fixing while you're in this function: $value (set line 116) is never reset per iteration, so a text/date/etc. answer processed right after a QuestionTypeItemDropdown answer silently reuses the previous answer's value via the ?? fallback at line 148.

Suggested change

	foreach ($answers as $answer) {
	$value = null;

[Rom1-B]

Suggested change

	- Fix value mapping between a multiple dropdown field and it's destination in a form
	- Fix value mapping between a multiple dropdown field and its destination in a form