Project workspaces

[philpax]

When working with many packages in a related project (i.e. a game, but not necessarily a game), there are a few common operations:

• sharing metadata between packages, including specific dependencies and their versions, as well as one version for all packages
• deploying the entire workspace at once, and not deploying what hasn't changed
• building packages for tests/etc that should share state with the rest of the workspace, but should not be published
• patching dependencies across the workspace so that they all match a temporary hotfix

We should consider formalizing this concept and build out workspaces to allow for this. The big inspiration is Cargo's workspaces, of course, but ideally it supports most of what a user wants to do out of the box.

@droqen and I have previously discussed the idea of a working group of packages, as opposed to a published group of projects, before. We're still thinking about whether it makes sense to separate those concepts. Do workspaces have a representation on the website, or are they a purely development concept?

[droqen]

The concept of a 'working group of packages' formalizes something that essentially already exists in fps_console: a layer for enabling/disabling packages within a group of related packages. Is it possible/desirable that this 'working group' could be its own package content type (possibly a particular type of tool), or is it categorically different?