website: Update input documentation & demos

[FlyersPh9]

• Add input demos for the different options.
• Update documentation, include adding hyperlinks to other mentioned components.

[mayank99]

"In most scenarios" is not right. Really we want it to be all scenarios. It's an accessibility requirement.

The use case for <Input> (over <LabeledInput>) is when using a separate <Label> or a hidden label (either using <VisuallyHidden> or aria-label).

[mayank99]

Continuing that logic, I'm not sure it makes sense to separate these two components as "variants". Instead, we could assume <LabeledInput> throughout the page, and then have a section (under Usage) for a "Standalone input".

[FlyersPh9]

I've removed the "In most scenarios" and explicitly stated that a label is an accessibility requirement. I've also removed variants and added a standalone section.

[FlyersPh9]

Most search inputs don't have a label, does search somehow get an exception?

[mayank99]

If the input has other contextual hints to help the user enter the right text (e.g. a search icon in the case of a search input, then a visible label can be omitted, but there still needs to be a hidden label. This hidden label could be associated using aria-labelledlby or <label> + VisuallyHidden for example.

[FlyersPh9]

Good to know, I'll try using <label> + VisuallyHidden on the search boxes in the demo pages of #1073.

[mayank99]

There are some merge conflicts.