Add remaining schema renderers

[antgamdia]

Description of the change

In #5436 we mentioned that several fields were still pending, namely

• 1st level: object (at least, as array of tuples <string, any> for defining each property.
• Array level: enum, arrays, objects

WRT the top-level objects, it is not an actual problem: if they have properties, they will get rendered as any other nested param more. It is only the case when it lacks the properties fields that we need to handle.

• Solution: allow any serialized object like {"foo": 1234} and add more validation messages.

WRT the array-level properties:

• Solution for enum: use the same approach as in the top-level enum.
• Solution for arrays and objects: use the same approach as in the top-level objects: render a text field but enforce validation.

Additionally, the array now enforces maxItems and minItems

Benefits

Every json schema datatype is now supported.

Possible drawbacks

N/A

Applicable issues

• fixes Create additional "JSON Schema form" param renderers #5436

Additional information

Note
This PR is part of a series of PRs aimed at closing this milestone. I have split the changes to ease the review process, but as there are many interrelated changes, the tests will be performed in a separate PR (on top of the branch containing all the changes).
PR 5 out of 6

Top-level objects:

Array<enum>:

Array<array>:

Array<object>:

YAML output

Array max/min items

Min items:

Max items:

[castelblanque]

Great, thanks for the improvement. Table looks really nice!
Shouldn't we add tests to avoid regressions? I mean unit tests here, the upcoming tests will be the E2E?

[antgamdia]

Great, thanks for the improvement. Table looks really nice!

Thanks! Definitely, editing the schema is a great addition for users wanting to create forms/schemas for their packages.

Shouldn't we add tests to avoid regressions? I mean unit tests here, the upcoming tests will be the E2E?

Absolutely! The point is that, given that the changes are pretty coupled, I just wanted to split the code to make the review easier, but I haven't actually tested each PR separately (meaning I for sure have forgotten to add a change that will be in another PR).
My approach is to add the e2e tests in a separate PR (which I'll create soon). I will merge everything but the first PR and then I'll create the one with the tests on top of it.