add options for ignoring specific lints

[MoralCode]

fixes #67

This adds two new flags in the constructor as documented (hopefully in a way that makes sense - may need rewording) in the README.

Features:

• this allows specific linter errors to be ignored by passing in an object containing some of the key properties that can identify an error (currently implemented: code, message, file). If all of the provided values match an error from the linter, that error is filtered out before deciding whether the program should raise an error or not.
• includes a shortcut (ignoreKnownChromeLintFailures) that ignore lint failures that are raised due to differences between firefox and chrome manifest formats (see Manifest Version 3 background.Service_Worker is currently disabled mozilla/web-ext#2532 for an example). This is not a mechanism that fullly supports validating chrome extensions, but it is a way to prevent this linter from failing when given a valid chrome extension
• plays nice with the existing lintWarningsAsErrors, allowing warnings to be filtered as well if this option is true

Testing:
Tested using the build scripts of a web extension I've been working on recently that uses this plugin. Output in most scenarios (such as with and without lintWarningsAsErrors, valid filters, invalid filters, and handling of junk data) seems to match what would reasonably be expected.

as an example:

filterLintFailures: [{
	code: "MANIFEST_FIELD_UNSUPPORTED",
	message: '"/background" is in an unsupported format.'
},
{
	code: "MANIFEST_FIELD_PPORTED",
	message: '"/background" is in an unsupported format.'
},{
	totally:"fake",
	data:"here"
}],

This sample data successfully filters the error indicated by the first rule, and essentially ignores the other two. This set of filters is (currently) the same as what ignoreKnownChromeLintFailures would add automatically.

Changes to be made:

• Bump version number (maybe? not sure what it should be set to)
• Automated testing would probably be a good idea to add given the number of combinations/branches of behavior involved here*

* I would do this, but I'm skeptical that the way I set up junit in a project recently may cause other things to break. maybe vitest as mentioned in the linked issue works differently?

[birtles]

This is spot on. Great job. Thank you!

[birtles]

I've published this now as v2.8.0. Please let me know if it works for you. Thanks again!