Feature request: allow choosing half or full width for each field in item forms #1288

Context

In item forms (tab or "insertion in the form" blocks), every field is displayed on
half of the row (col-12 col-sm-6), so two fields share one line. Only rich text
fields and fields displayed in the ITIL side panel or the form builder use the full
row width.

This layout is fine for short values (yes/no, dates, numbers), but it is not
adapted to some fields:

• long text values or URLs are truncated or wrapped in a narrow input,
• multiple dropdowns with many selected values grow vertically instead of using
  the available space,
• some fields are more readable alone on their line, for instance a field that
  introduces a new group of information.

There is currently no way to control this from the field configuration.

Proposal

Add a "Width" option on each field, next to "Read only":

• Half width (1 column): current behaviour, the default value
• Full width (2 columns): the field takes the whole row

The GLPI form macros already support this through the full_width option
(col-12 glpi-full-width), and GLPI's CSS keeps the label aligned with the labels
of half width fields. So the change would be small:

1. a new is_full_width boolean column in glpi_plugin_fields_fields
   (default 0, added by the migration, so existing fields are unchanged),
2. a selector in the field form,
3. in templates/fields.html.twig, set full_width when the field is configured
   as full width (header fields are not concerned, they already use the whole row).

Contexts that already display fields on full width (ITIL side panel, form builder)
would keep their current behaviour.

Open questions

• Should rich text fields, which are currently always on full width, follow this
  option too? This would change the current display for existing fields, so I
  would leave them as they are unless you prefer otherwise.
• Would you rather have this setting at the block level (all fields of a block on
  full width) instead of field by field? Field by field seems more flexible.

I have a working implementation and can open a pull request if this approach
suits you.