docs(form-field): update custom form field control docs

[dgriffin123]

Documentation Feedback

The guide to create a custom form field control is beyond confusing. Some suggestions:

• The stackblitz is very very hard to read. There is one .ts file with 2 components and 3 classes, and one of the components in the file references a separate template file with a completely different name. Why not just use another file altogether for the .ts and use the same name as the template?
• The accessibility section briefly mentions things like setDescribedByIds(), but the actual implementation doesn't even use many things mentioned (and when I tried to use the exact example, was met with many errors I couldn't get past).
• accommodate strict typescript settings, which many people use/are forced to use at work. I ran into many problems with this. Many @Inputs needed to be initialized, and I wasn't sure if I should just use the safe navigation or non-null assertion operators. I think the official documentation should be using the strictest forms of typechecking/null checking instead of the many "any" types that are so often used (not in this guide, but elsewhere in angular docs). It would make things much easier, and also stop teaching so people bad habits.

Affected documentation page

https://material.angular.io/guide/creating-a-custom-form-field-control

[wagnermaciel]

For the first bullet point, I disagree. Having two components defined in a single ts file pointing to two separate html files doesn't increase the complexity. Preference on how code in the examples is structured is not something we would take action on, sonless others also find that this has a significant impact on their ability to understand the example we most likely won't adopt this change

For the a11y and strict ts issues, the original purpose of this docs example is not to be perfect battle-tested and ready to use implementation of a phone input. Its only goal was to demonstrate some of the capabilities of the custom form field control

That being said, I'll keep this issue open so our team can discuss potentially enforcing strict ts, no a11y warnings, etc. on our docs examples