feat: support CLI multiple projects

[tzachbon]

This PR is part 2 of CLI improvements #1996

Goals

• support multiple projects build.
• build by topological order by default.
• build multiple outputs for a specific request.
• options override for a specific request.
• creation of multiple presets.
• override options of a specific request with preset.
• override a preset value for a specific request.
• handle watch mode.
• watch cache invalidation optimization.
• BUG FIX - copied assets and generated manifest do not mark as generated.
• BUG FIX - graceful error handling for build processes.
• create full "e2e" test with fake node_modules.
• add top level file processor cache to all entities.
• remove manually added .js extension from resolved paths when fix!: unify resolvePath, always resolve request via resolver and remove resolve from fileProcessor #2135 merged.
• adjust logs in watch mode.
• Update the Generator name to IndexGenerator.
• Remove extension option.
• open tech-debt issue to move all log from CLI to messages.ts.
• add to documentation.

Changes

• Add new dependency @wixc3/resolve-directory-context for the default projects resolution.
• Export type helpers from the index.
• A lot of types were added and changed.
• Created messages file that contains all the output messages that we are using across the CLI.
• visitMetaCSSDependenciesBFS supports js dependency callback
• Config - split into 3 main files
  • resolve requests - the default requests resolution method. It will take the project raw entities and will output the resolved project in the relevant order.
  • resolve options - includes options calculation methods.
  • process projects - has the process project main method that resolves multi-project config to raw project entities.
  • projects config - this is the main file related to config resolution that exports the projectsConfig method which is the main method for resolving the projects.
• Build -
  • Split the build method into two parameters (build options [defined by the user], and build metadata).
  • Each build has an instance of DirectoryProcessService which works only on its relevant scope.
  • After the initial build, the scopes have a map that includes all of the files dependent by list (the opposite of dependency).

• The builds share a map of all of the files meta-data that understand each files src path and out paths.
• In the top-level context there is a DirectoriesHandlerService which handles watch and watch cache.

• Currently we managed the diagnostic pretty much in a straight-forward way which does not work in complex situations that the multiple projects and builds introduced. A diagnostic manager was created to solve this issue by managing all the diagnostic in a high-level manager to be shared between all processes.

Testing

• generate-index and build specs were changed to match the new build method API.
• config-options spec tests the resolution of options.
• config-presets spec test the resolution of presets and multiple presets.
• config-project spec tests all of the cases that can occur from multiple projects (resolution order, multi-options resolution, etc...)
• cli-watch refactor to support tests for single build and multiple builds.
• Moved cli-test-kit to @stylable/e2e-test-kit.

Test helpers

• the watch CLI test-kit now supports delay after the steps are completed (it is used to make sure in specific tests that there is no extra logs / circular build after the steps are finished).

[barak007]

Great work

[tomrav]

left a couple of comments for the readme