docs(KEP): Support Literal pipeline input parameters

[alyssacgoins]

Description of your changes: KEP to implement #11385

Checklist:

• [X] You have signed off your commits
• [X] The title for your pull request (PR) should follow our title convention. Learn more about the pull request title convention used in this repository.

[google-oss-prow[bot]]

Skipping CI for Draft Pull Request. If you want CI signal for your change, please convert it to an actual PR. You can still manually trigger a test run with /test all

[google-oss-prow[bot]]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: Once this PR has been reviewed and has the lgtm label, please assign droctothorpe for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment Approvers can cancel approval by writing /approve cancel in a comment

[Ark-kun]

We could utilize the flexibility of the KFPv1 ComponentSpec type system:

inputs:
  - name: input_1
    type: {String: {enum_values: ["a", "b", "c"]}}

Also, in KFPv1, the ComponentSpec format supports InputSpec annotations. They allow adding and experimenting with arbitrary metadata without making long-term changes to the component specification.

Here is how this could look:

inputs:
  - name: input_1
    type: String
    annotations:
      enum_values: '["a", "b", "c"]'

[alyssacgoins]

We could utilize the flexibility of the KFPv1 ComponentSpec type system:

inputs:
  - name: input_1
    type: {String: {enum_values: ["a", "b", "c"]}}

Also, in KFPv1, the ComponentSpec format supports InputSpec annotations. They allow adding and experimenting with arbitrary metadata without making long-term changes to the component specification.

Here is how this could look:

inputs:
  - name: input_1
    type: String
    annotations:
      enum_values: '["a", "b", "c"]'

Hey Alexey - thanks for taking a look at my PR - my thinking here is that adding a literals field as opposed to a literals entry under annotations creates logic that is easier to follow.