Move ES UI form lib from es_ui_shared plugin into a package

[cjcenizal]

After discussing this, ES UI has decided this move is worth the following benefits:

1. Enable lazy loading. The form lib has a dependency upon brace/mode/json which adds 48kb to the page load bundle size ([ES UI] Reintroduce import of brace/mode/json #78571 (comment)). Moving the lib to a package will reduce the page load bundle size by more than this amount.
2. Clarify purpose of code. It seems like an anti-pattern to present static library code as a plugin, when it has no dependency upon other plugins and is agnostic to the plugin lifecycle. Encapsulating this code within a package sets the appropriate expectation for developers about what's inside.
3. Prepare for broader adoption. Currently, we want to limit the consumption of this library due to lack of capacity for maintenance and support. We can enforce this limit in the README and docs. Once we grow our capacity for supporting more consumers, a package will be easier to discover and consume than a plugin. After discussion with Stacey, we agreed that the long-term plan for the form lib isn't clear enough to consider this as more than a speculative benefit.

CC @kobelb @stacey-gammon

[elasticmachine]

Pinging @elastic/es-ui (Team:Elasticsearch UI)

[kobelb]

@elastic/kibana-operations do you know how far away we are from effectively no longer requiring that static-code that wants to be shared reside in the packages/ folder?

[spalger]

@kobelb can you give me some more details about what you mean by "static-code that wants to be shared"?

I think the code sharing we've enabled between plugins qualifies, but I could interpret that a number of ways and I don't think that packages improve our ability to share code other than the fact that prevents us from needing to use relative import paths. Is that what you mean?

[kobelb]

@spalger apologies for the vague phrasing. It's my understanding that as part of the move to Bazel, that we'll be removing the differences between packages/ and the code that currently resides in the plugins/ folders, and both of these will just be considered a "project".

Long-term, we plan to change the code organization entirely and use a domain-based approach per #71566, which would get rid of the packages/ and plugins/ folders.

[spalger]

Hmm, sounds like a question for @mistic and @tylersmalley then, I don't think that Bazel will be removing all of the differences between packages and plugins, and but I'm not super up-to-date with those plans and maybe we'll be accessing plugins as top-level node modules in the future like we do with packages today...

[elasticmachine]

Pinging @elastic/kibana-management (Team:Kibana Management)