As a Dev, let me write a package manifest exposing components and configs

[adaburrows]

Any package will be exposing some combination of:

• Resource Schemas
• Resource Views (Create, View, Edit)
• List Views
• Page Layouts
• Assessment Components
• Applications (which can access spaces and operate on resources with schemas they understand)
• Configurations
  • Dimension compute graphs
  • Assessment tray configs
  • List configurations (List View, [Resource Filter, Resource Filter, ...], [Threshold, Threshold, ...], [Ordering, Ordering, ...])
  • Page Configurations (Page -> Layout -> [Slot -> View, Slot -> View, ...])

[adaburrows]

Also see #182, since there may be significant overlap in the config, though not necessarily. The other config may stay separate and refer back to these configs and determine which portions of the config are active. Additionally, the dev config may need to specify ports that dev servers will be configured to run in order for HMR to work.

[adaburrows]

Each package containing multiple objects can be served over a single URL from a web server (this would satisfy #194 and possibly #195). I was originally thinking that each object in a package could be its own project with its own dev server, but it doesn't make sense to waste so many sockets.

Additionally, #196 has overlap with this since versioning should be taken into consideration and old versions should be maintained in the package repository server (akin to how Linux distro repos work).

We should also take care to specify which versions of Neighbourhoods a package is compatible with, especially since we are currently changing the API quite a bit.

Also, as long as a web 2 application has a link to a Neighbourhoods manifest, we can understand how to extend it into Neighbourhoods (or it can specify how to read it's data into Neighbourhoods). This would satisfy #197.