feat: support io.Reader based parsers

[G-Rath]

Resolves #176

[another-rex]

I think we need to discuss how you want to handle transitioning from "cli" to "library" given that everything there is currently "parse-as"; I think we could either keep it as is, go for a hybrid approach, or rename everything non-breaking to "extract-as".

I think the CLI actually doesn't mention "parse" at all right? To specify a parsing method we are using the Cargo.lock:/path/to/Cargo.lock, and taking a look at osvscanner.go, the parse and parseAs mentions are argument names are all private variables / argument names.

I think we can go ahead and rename non breaking things to extract, but haven't looked into it enough to see how practical that is.

The part where the code actually suffers currently is in FindExtractor, because the Gradle extractor has two different files but the Extractor interface doesn't support convoying that back - for now I've just duplicated the ShouldExtract into the FindExtractor code.

Hmm I'm not clear on what you mean here. I had a look at FindExtractor in this PR, and I don't think stabilizeFindExtractorName is necessary, since both gradle files are parsed the same, we can just decide on a parser/extractor name and return that, unless I am missing something?

[another-rex]

Looks pretty good! Just some minor comments.

[oliverchang]

nice, thanks @G-Rath !!! looks pretty good overall.

[oliverchang]

Is it worth creating constants for these names for all extractors, and using them in both ShouldExtract and init ?

[G-Rath]

Practically no because I don't see a strong value in doing that now since it's not like it'll make the code faster or anything, and architecturally I'd argue you're conflating "extractor names" with "file paths"