feat: add function to unregister post analyzers

[samuelvl]

Description

Analogous to DeregisterAnalyzer but for post analyzers:

trivy/pkg/fanal/analyzer/analyzer.go

Lines 110 to 113 in c9ba460

	// DeregisterAnalyzer is mainly for testing
	func DeregisterAnalyzer(t Type) {
	delete(analyzers, t)
	}

[CLAassistant]

All committers have signed the CLA.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[simar7]

hi @samuelvl - I'm curious but what's the use case for this?

[samuelvl]

Hey @simar7, we are using Trivy as a library and we need to deregister analyzers before enabling them to avoid Analyzer is registered twice errors. For example https://github.com/castai/image-analyzer/blob/main/apk/apk.go#L25-L26

Since dpkg is now a post analyzer we need to do a similar thing but with DeregisterPostAnalyzer. Let me know if it makes sense or if there is a better way of doing this.

[DmitriyLewen]

Although these functions are mainly used for testing, users can also use them.
We have Disable* functions for analyzers and configAnalyzers.
So i think we can add this function.
cc. @knqyf263

@samuelvl there is 1 more way (and i think this is more correct way):
you can use DisabledAnalyzers field.
But your analyzers should use different names.

[knqyf263]

@samuelvl As Dmitriy mentioned, doesn't DisabledAnalzyers work for you? You can use a different name and disable the existing one.

Also, since Trivy is a CLI tool, not a library, we do not guarantee source code compatibility, so using it as a library is not recommended. However, users may use it as a library at their own risk.

[samuelvl]

This is finally not needed, thanks for the support 🙏