Enhancement/issue 946 decouple build and serve commands from workspace

[thescientist13]

Related Issue

resolves #946

Summary of Changes

1. Bundle API and SSR routes and created a manifest.json
2. "Hydrate" serve command + hybrid server using graph.json and manifest.json to manage serving API routes and SSR pages
3. Decouple serve command from running build and serve (greenwood serve now requires that a greenwood build has been run)
4. Created a lib/template-utils.js and added (Greenwood's) templateDir to context

TODO

1. [x] Flesh out remaining templating use cases (should get all tests passing)
2. [x] Decouple serve command from bundle lifecycle and add test case in /cli/src/index.js and update specs
3. [x] Testing
   • Static Router spec failing / conflicting (seems to be because of needing to scaffold lib/router.js)
   • serve pre-requisite on build (warning spec)
   • Test output files for SSR and manifest.json (save for dedicated issue on consolidating build output?)

4. [x] Address issue with WCC and wrapping tags (related to wcc wrapping based on any definition it finds now that we are bundling) - https://github.com/ProjectEvergreen/wcc/issues/114

   <x-card>
     <h1>List of Artists: <span id="count">11</span></h1>
   
     <x-card name="Analog">
       <h1>Hello Analog</h1>
   
       <img slot="image" src="//d34k5cjnk2rcze.cloudfront.net/images/artists/analog.jpg" alt="PIcture of Analog">
     </x-card>
   
     <x-card name="Electro Calrissian">
       <h1>Hello Electro Calrissian</h1>
   
       <img slot="image" src="//d34k5cjnk2rcze.cloudfront.net/images/artists/electro-calrissian.jpg" alt="PIcture of Electro Calrissian">
     </x-card>
   
     ...
   
   </x-card>

5. [x] Consolidate template-utils.js / align with standard HTML plugin and leverage a consistent templatesDir context
6. [x] Documentation (build + serve commands)
   • Need node_modules
   • need greenwood.config.js
   • need output directory
7. [x] clean up console logs / track TODOs
8. [x] Context plugins in SSR routes?
9. [ ] "vendor" new rollup plugins (nice to have)
   • json
   • import URL

Thoughts / Questions / Enhancements Tracking

1. [x] Should probably consider putting resources and other compilation related information into manifest.json and document as build output with tests. (could do this as a guide?) - https://github.com/ProjectEvergreen/greenwood/issues/1008
2. [x] better way to DI compilation into SSR pages instead of through handler? (probably include as part of serverless work) - https://github.com/ProjectEvergreen/greenwood/issues/1008
3. [x] Does it make sense to ditch Workers? Causing a bit of overhead here and maybe could be an option instead (if using Node?) 🤔 (see similar thoughts raised in https://github.com/ProjectEvergreen/greenwood/issues/970) - https://github.com/ProjectEvergreen/greenwood/issues/1088
   • To the above, if we ditch workers, we might not have to do the whole generated code output like we're doing to split the page code from the worker code?
4. [x] Should API and SSR pages have chunks, or be entirely self contained (per #1008 ) and also minified? - https://github.com/ProjectEvergreen/greenwood/issues/1008
5. [x] Should probably upgrade Rollup (v3?) and ours plugins? - https://github.com/ProjectEvergreen/greenwood/issues/1087
   • Ran into this issue with fs/promises - https://github.com/rollup/plugins/issues/1120
   • I think v3 comes with nodeResolve plugin by default?
6. [x] Added more Rollup plugins would be good to figure out this, or maybe consider esbuild if it has all this out of the box and is more "web api" friendly? Related to Rollup is a leaky abstraction distraction - https://github.com/ProjectEvergreen/greenwood/issues/1087
   • avoiding JSON in escodegen - https://github.com/estools/escodegen/issues/455
   • to the above, JSX deps in WCC could be made opt-in instead at least - https://github.com/ProjectEvergreen/wcc/issues/116
   • create our own URL plugin implementation (seems easy enough)