Prevent ID conflict in ParameterIncludeEmpty

[masflam]

Description

Remove id and htmlFor attributes from the checkbox and label accordingly, inside of ParameterIncludeEmpty.

Motivation and Context

Fixes #10890.

The ParameterIncludeEmpty component is used when editing an application/x-www-form-urlencoded request body whose schema defines an optional property. It's a labelled checkbox that controls whether the body being edited is to contain a given property at all. When multiple properties are optional, multiple of these checkboxes and labels are rendered. The problem is that each one got the same hard-coded HTML element ID, and each label was for= that same ID, resulting in all the labels controlling the same checkbox. (the first one in the DOM in my browser)

Since a label by default controls any input nested inside it, these id and for attributed were completely superfluous. Without them clicking on each label works as expected, toggling the appropriate checkbox only.

How Has This Been Tested?

Ran npm run test to see nothing else broke and npm run dev to see that the changes resolved the issue.

Checklist

My PR contains...

• No code changes (src/ is unmodified: changes to documentation, CI, metadata, etc.)
• Dependency changes (any modification to dependencies in package.json)
• Bug fixes (non-breaking change which fixes an issue)
• Improvements (misc. changes to existing features)
• Features (non-breaking change which adds functionality)

My changes...

• are breaking changes to a public API (config options, System API, major UI change, etc).
• are breaking changes to a private API (Redux, component props, utility functions, etc.).
• are breaking changes to a developer API (npm script behavior changes, new dev system dependencies, etc).
• are not breaking changes.

Documentation

• My changes do not require a change to the project documentation.
• My changes require a change to the project documentation.
• If yes to above: I have updated the documentation accordingly.

Automated tests

• My changes can not or do not need to be tested.
• My changes can and should be tested by unit and/or integration tests.
• If yes to above: I have added tests to cover my changes.
• If yes to above: I have taken care to cover edge cases in my tests.
• All new and existing tests passed.