fix: align with guidance on input type for numbers (NumberField)

[sfount]

Description

Bring the NumberField component inline with the GOV.UK design system guidance on how to ask for numbers.

Update the HTML attribute type from "number" to "text" which stops the browser from restricting which type of characters can be entered into the input - this restriction can be confusing for users, limit the ability to copy & paste and has proven problematic for screen readers.

As the current NumberField component uses joi.number() as the base schema there will already be server side validation ensuring that if anything that can't be parsed by Number() is entered (text or invalid decimals) the user will be prompted to enter a number.

New behaviour: component already validates the input value against Joi number schema, even if the form allows the user to submit

Setting the inputmode attribute to "numeric" will still prompt mobile browsers to provide a keyboard specifically for numbers and decimals (note on the mobile browsers I've tried this change against the keyboard behaviour is currently identical to if the type attribute was set to number).

Current behaviour: mobile keyboard	New behaviour: mobile keyboard

This change does still fallback to the type "number" if the precision option is set on the components schema. Although I wouldn't advise this was used the step attribute which is set on the HTML input will not work if the type is set to "text". Adding custom server side validation to validate and clearly feedback on incorrect decimal precision seemed well out of the scope of this fix and this should allow existing configurations to work as-is. (Note from an early review it looks like setting the precision option doesn't actually appropriately set different granularities of step but I'll look to raise that as a separate issue).

This change aims to bring the NumberField inline with the guidance found here: https://design-system.service.gov.uk/components/text-input/#numbers

Specifically attempting to fix the issues described by: https://design-system.service.gov.uk/components/text-input/#avoid-using-inputs-with-a-type-of-number

A more detailed description of why the guidance was set was published in Feb 2020:
https://technology.blog.gov.uk/2020/02/24/why-the-gov-uk-design-system-team-changed-the-input-type-for-numbers/

---

Note that because the date part and date time part components use the govuk-frontend macro govukDateInput directly (by passing items into the macro options) those components are already asking for numbers using the appropriate type "text" and inputmode "numeric".

Type of change

Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?

Although the form builder is used in my department this issue was identified during an internal demo between designers and developers. It was not flagged as an issue by end users.

This commit updates to try and align the code to the design system guidance but has not been tried in a real world scenario with users submitting data.

Checklist:

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas