move agg_types and agg_configs to data plugin

[ppisljar]

Summary

Summarize your PR. If it involves visual changes include a screenshot or gif.

Checklist

Use strikethroughs to remove checklist items you don't feel are applicable to this PR.

• This was checked for cross-browser compatibility, including a check against IE11
• Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support
• Documentation was added for features that require explanation or tutorials
• Unit or functional tests were updated or added to match the most common scenarios
• This was checked for keyboard-only and screenreader accessibility

For maintainers

• This was checked for breaking API changes and was labeled appropriately
• This includes a feature addition or change that requires a release note and was labeled appropriately

[elasticmachine]

Pinging @elastic/kibana-app-arch

[elasticmachine]

💔 Build Failed

• continuous-integration/kibana-ci/pull-request

[lukeelmers]

I've only looked at the initial directory structure. A few thoughts:

• we could take this opportunity to convert setup.ts to legacy.ts (the agreed-upon convention for shim code). since you are already updating a bunch of imports anyway, this would prevent you from needing to do them again...
• are we planning to statically import all of the agg_types/agg_configs code? or should we have an aggs service, e.g. data.aggs.types and data.aggs.configs or similar?
• even if we are only doing static imports, i might still advocate for doing them under a single aggs directory
• for the static imports, we should probably still be exporting those from the top-level public/index.ts rather than doing our imports from public/np_ready. or perhaps you were doing this as a temporary step?
• i have some ideas for how we could handle exporting the static stuff a bit more cleanly; will bring this up tomorrow