feat(RequestBody): validation support for required fields

[tim-lai]

fixes #5181

Description

Changed how UI receives x-www-form-urlencoded form data. Specifically, set requestBodyValue values to be an immutable Map, as "value". Previously stored as a normal String.

This change enables the ability to add "errors" to a Map that can be used by validation.
This change also matches the existing behavior of OAS2, and OAS3 Parameters

For application/json and application/xml, the "errors" field is added directly to the bodyValue Map

Example: 
Old: ...pathMethod,..., bodyValue Map { "id": 10, "name": "doggie" }
New: ...pathMethod,..., bodyValue Map { id: Map { value: 10, errors: List[] }, name: Map { value: "doggie", errors: List[] } }

For all other Request Bodies, e.g. Markdown, 
Old: ...pathMethod,..., bodyValue Map { value: ""}
New: ...pathMethod,..., bodyValue Map { value: "", errors: List[] }

• Dev note: getOAS3RequiredRequestBodyContentType requires state.spec, which is not available to state.oas3

Motivation and Context

Fixes #5181

For OAS3 Request Body, if required fields are empty, user should not be able to "Execute" and get a response. In addition, the missing required fields should be highlighted in Red.

How Has This Been Tested?

new cypress and mocha tests

Screenshots (if appropriate):

application/x-www-form-urlencoded

application/json (application/xml is similar)

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.

[tim-lai]

please build