Implementation of .NET Extractors

[Octaviusss]

Pull request for the .NET extractors.
Implemented:

• Extractor implementation for package.config and .deps.json;
• Unit test implementation for both extractors:
• Integration of the extractors in the main tool;

[vpasdf]

In the test files I see also targets. Why only libraries and not targets? Document in a comment what the difference is and why we only care about libraries

[Octaviusss]

The libraries section provides a mapping of package names to their versions, which is exactly what we need to extract for .NET packages. It lists all the packages used in the application, whether project references or external dependencies, along with essential metadata.
Since we only require the package name and version, the libraries field is sufficient for our needs.

The targets section just includes additional information such as runtime and dependency information. Focusing only on libraries was a choice based on the simplicity it offers in parsing. By avoiding the nested structure and complexities of the targets field, we keep the parser lightweight and efficient.

[vpasdf]

Thats useful information, please add this information in the code as a comment. I.e. what libraries contains and what targets contains and why we don't extract targets.

second question: Do the .deps.json files contain information of which package it is in? I.e. package.json specifies which package it is and it's first level dependencies. package-lock.json defines a list of packages with pinned versions, which fullfill the package.json requirements. I guess the library part in deps.json is like package-lock.json. Now the question is if target contains information of the actual package, like package.json does.

[Octaviusss]

The .deps.json file does not directly specify which package/project it belongs to in the same way package.json does.
You can just infer the project from the libraries section by identifying the entry with "type": "project".
The targets section does not provide this information since it focuses on runtime-specific details of dependencies, it just lists all runtime dependencies for the project and its transitive dependencies, but it does not explicitly highlight which package or project the deps.json file represents.

[vpasdf]

Then I think it's valuable to add type to the metadata. You can add a comment that if this field is project, it's the root/main package (idk whats the best name here, up to you).

Does libraries contain transitive deps? If not please document.
If targets contains transitive deps and libraries does not, please document that as well, in case we want to add it later.

document = comment in the code.

[vpasdf]

Please fix the highlighted issues

[vpasdf]

(same as in #357)

Usually each result type of plugins has their own metadata struct. This is used in some use cases of Scalibr to distinguish result types

So you either add a metadata proto for .net. Then you need to update proto.go and scanresult proto. This is used in some programs to differentiate different result types. It's also recommended to have all necessary information in metadata for matching.

Or you don't, then that change is not required.