Convert to monorepo pkg management

What does this MR do?

Re-organizes this repository to use a monorepo project manager called lerna which provides a logical separation between different types of security reports to include their test functionality. Lerna enables independent version control, tagging, and publishing all within a single repository with package isolation.

Design Methodology

• Create individual modules/packages to represent a single security report format
• Consolidate specialized/individualized code into corresponding packages
• Test cases should be as close to the source code they test as possible
• The primary objective is to build packages that are self-contained and dependencies managed through npm package managers. This means a single package will have its own build & test scripts. These can be run in isolation or run all tests across all packages via lerna.
• The top level project maintains code that requires more than one package or applies to the entire project but attempts to push down code to the packages if it is too specific. Lint configurations, CI configurations, dev dependencies, support libraries, and integration tests are ideal. This draws the most opinionated discussion since schema-merge is really core tool which all others use as a dependency. So common library like functionality is placed in schema-merge to allow packages to apply the code to themselves rather than long filepath imports.

Why?

During my previous MR !75 (merged), @fcatteau, was interested in the concept of what security-report-schemas as a monorepo project would look like but recognized it was outside the scope of the previous MR. Subsequently, he suggested a separate MR could be generated to facilitate the discussion towards adopting a monorepo project manager. This is that MR. I took it as a challenge to learn and hopefully help the future of this project.

@cam_swords, I know you had reservations for lerna due to learning curve & amount of transition and after doing it, it was a significant venture but here it is. I was able to lower the lerna learning curve through the use of the top-level npm scripts which programmatically call lerna which means you only technically need to know how to use npm run-scripts.

I would highlight the best capability this can bring is independent SchemaVer management per security-report-format type. This way a change to the extension template of one format does not imply an update of other format whereas a base format change would impact all. Lerna has functionality built in to isolate and inform this decision across the project.

In this MR, I reviewed basically every line of code to determine its scope and focus. When doing so I was able to remove many hardcoded file references through integral use of the npm ecosystem functionality (automatic PATH modification via node_modules/.bin/).

Availability & Testing

I had to transition the pipeline to work with the new file organization but now all tests pass and are run either the same scope or more thorough results.

Upon request, I will gladly provide context to the design decisions made in order to maintain or transition the current repo to this organization. This will likely conflict with MR !78 (closed) when it comes to the pipeline configuration so I can adjust accordingly.

Evaluation

Pros

• (see Why)

Cons

• 1 changelog => 7 changelogs require manual maintainence
• A package tag points at the repository and contains entire repo rather than only its package
• Tags are now heavy-weight vs lightweight = larger size .git folder