Refactor: Change Plugin Architecture

[nishakm]

Summary

Update the project's plugin architecture to use actual compile-time Go plugins

Background

The project's current Plugin setup does not actually allow other tools to "plug-in". database/sql is an example of the "plugin" pattern implemented in Go. This example explains how the pattern is implemented.

This implementation allows us to do the following:

• Clearly define the goal of the project
• Allow the parsers project to be developed independent of this project
• Allow other tools to use the project to generate SPDX SBOMs

Project goal

The goal of the project is currently ambiguous. It should be concretely to "generate SPDX SBOMs given data about software". From this statement, we can separate the "data" from the "generation". Hence the Plugin should allow for independent implementers to provide this data in a particular way.

The overall architecture should look like this:

Now we can concentrate on the architecture of the Plugin Interface and the Generation part.

Proposed architecture

The project goal is to support SPDX specification 2.3 onwards and 3.0 onwards. The two data models are significantly different. In order to support future data models and scenarios, the proposal is to create Plugin Interface that returns a generic SPDX data struct with its corresponding version. The implementation of creating the SPDX data struct for each version then falls on Plugin implementers.

Currently SPDX's golang-tools provides some structs which we can enforce implementers provide.

[nishakm]

@ba11b0y I'll be using this space to document thoughts about how to implement the Plugin interface.

[nishakm]

@puerco's proposed changes https://github.com/opensbom-generator/spdx-sbom-generator/pull/294