[lockfile-explorer] Move graph generation logic to the server process

[octogonz]

Summary

This is another refactoring change, continuing the work from PR #5357

Details

• This PR moves the lfxGraphLoader.ts logic so that it is now performed by the Node.js server rather than in the browser. This will pave the way for lots of improvements leveraging Node.js NPM packages to correctly parse multiple lockfile formats.
• The serialized LfxGraph is now transmitted to the client using a new /api/graph endpoint, which also includes the workspace configuration. This eliminates the original /api/lockfile endpoint.
• This requires sharing code between client and server. My approach was to move lockfile-explorer-web's shared code into a packlet, which enforces that its imports cannot go outside its folder. Then lockfile-explorer (the server) uses heft.json to copy the packlet into temp/lfx-shared/. This folder needs to be included in the published NPM package, because lockfile-explorer-web is only a dev dependency.
• Fixed some problems with the local packlets ESLint rule config.
• Further improve the graph type names in 949f587
• Add some unit tests for lockfile verisons 5.4 and 6.0
• Enable the Rush Stack ESLint rules for lockfile-expolorer. (The lockfile-expolorer-web project was also using relaxed lint rules, but IIRC that was because of problems with ReduxJS heavy reliance on inferred types.)

How it was tested

• Tested by running against a lockfile from the repository: https://github.com/microsoft/lockfile-explorer-demos
• Created a unit test for the new code

Impacted documentation

None

@william2958

[iclanton]

Importing from something called temp is weird. Why not just lfx-shared?

[octogonz]

I've moved it from lockfile-explorer/temp/lfx-shared to lockfile-explorer/build/lfx-shared and added build/ to .gitignore. Docusaurus already uses build for built outputs, so this is pretty conventional.