Add aria-controls to aria props

[owenatgov]

What/Why

Adds aria-controls to the list of props in ariaProps.

Previously, we've made the decision to not include aria-controls in favour of aria-owns for better compatability with aria 1.0 and therefore better compatability with screen readers. See Nick's comment and Ollie's comment on this topic.

This has been re-prompted by a DAC audit of the GOV.UK Design System website, where we use the autocomplete for our search. DAC advised the following:

The combobox is missing the required aria-controls attribute. The lack of the aria-controls attribute on the combobox can be problematic as it does not associate the relationship between the combobox and its corresponding listbox. The aria-controls attribute is fundamental for providing an explicit relationship between these two elements, which is necessary for users who rely on assistive technologies such as screen readers. While there is an aria-owns attribute present and some user agents might support this, for backwards compatibility it is strongly recommended that the aria-controls attribute is implemented instead.

Following testing with all current major screen readers on aria-owns, aria-controls and both, we've found no difference between the 3 scenarios. Therefore, we can confidently add aria-controls to our aria props and remove aria-owns.

Resolves alphagov/govuk-design-system#4004
Resolves #565

Notes

The testing isn't complete yet due to difficulties we've been having testing on mobile devices. Based on desktop testing, it's unlikely that anything's going to come out of mobile testing, however for completeness we'll aim to resolve mobile testing before merging.

[owenatgov]

I'm going to have to close this and reopen it as a different PR in order to trigger a netlify deploy preview for testing