Consider refactoring secure analyzer ruleset package on top of report package

The following discussion from gitlab-org/security-products/analyzers/vulnerability!1 should be addressed:

• @fcatteau started a discussion: (+1 comment)

  Side note: I believe ruleset could and should be implemented on top of vulnerability, to increase composability. I know this is out of scope since it comes from the original issue package, but I want to bring that up since this MR is about reorganizing the code. I'll open a MR or refactoring issue to discuss this, if time permits.

  Conversation starter: ruleset is just one way to filter the report, similar to filterpath, and ruleset config is similar to *_EXCLUDED_PATHS. Filter configuration either belongs to the report, or it doesn't. If it doesn't, then Config should be renamed to be more generic, and next step it to describe the configuration as part of the scan object. If it doesn't, then ruleset and similar filters should be moved out of this vulnerability package.