Add initial component interfaces & basic node rendering

[ohltyler]

Description

This PR accomplishes 3 main things:

1. Sets up the base interfaces that will represent all of the different building blocks / UI components users will select to construct workflows.
2. Implements interfaces for 2 components: 1/ a text embedding processor, and 2/ a k-NN index.
3. Sets up a basic WorkflowComponent React component that's purpose is to take in a component instance (a particular k-NN index, for example), and dynamically render based on its configuration. An example with more details is shown below.

Example:

• shows the same WorkflowComponent building out instances of a text embedding processor and a k-NN index.
• k-NN index component supports creation, so it has a tabbed portion to toggle the inputs based on if user wants to create a new index, or use existing
• based on the input types, renders differently (text vs. select vs. JSON, etc.)
• inputs/outputs displayed there for readability & debugging purposes
• dummy values used for the indices and the created components

screen-capture.15.webm

Adding a rapid label to indicate this PR may not be perfectly clean or have tests. It is for rapid iteration.

Issues Resolved

Makes progress on #4.

Check List

• Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[jackiehanyang]

using index as a key isn't always a problem. But if the list can change over time, will it cause issues and even potentially introduce bugs? Do we have other unique identifier in IComponentField that we can use and the key here?

[ohltyler]

Using the index as a key for items in a list is a common JS pattern since it is calculated on-the-fly for each render. This will likely change a lot as we iterate so prefer to leave for now.

[jackiehanyang]

nit: instead of using a switch statement, consider refactoring it to use a mapping object for better clarity and scalability. This also makes adding new input types in the future easier

[ohltyler]

Thanks. Likely this will be moved into more complex helper fns as the number of object types will grow, and the complexity to render them will grow. Prefer to just leave as a simple switch for now.