feat: Create a verifier as a service

[laurentsimon]

See #163

This PR was originally started in #164 . There was a large file accidentally pushed in one of the commits. After removing it, the PR got automatically closed. Hence this new PR.

This is an experimental feature, obviously. This PR does:

1. Re-factor code to be able to share the verification code between the cli and the service
2. Implement a simple REST API /v1/verify which takes as input the same as the CLI (except for the artifact which is replaced by its hash):

{
    "source": "github.com/ossf/scorecard",
    "artifactHash": "02e7ac9a2a252a4e57cb2050953e787d095a04b955a41878068d60885bd31a0b",
    "tag": "v4.4.0",
     versionedTag: "bla",
    "printProvenance": true,
    "provenanceContent": "..."
}

Example: curl -s 127.0.0.1:8000/v1/verify -d @./request

and returns:

{
   "error": "some caught error"
   "validation": "failure" / "success"
   "provenanceContent": "base64 intoto"
}

We may want to change some of the names. I have not included unit tests yet. Will do in a follow-up PR. (need to mock the http client).

Let me know what you think about the input / output format. I'm wondering if we should unify the output for both the cli and the service. It would force us to have proper error / log handling

[asraa]

lgtm to keep iterating on

[asraa]

I know this matches the CLI options, but do you think the API needs to return provenance at all? this is a service that will be used to just get a pass/fail option. unless maybe someone wants to pipe in the result to other services to do more analysis on the provenance.

[laurentsimon]

Yes, someone may want to check for repository-id and what not. It's an optional argument, so is not needed. Is that OK?

[laurentsimon]

We will iterate, so I'm going to merge. This PR is just to get the ball rolling with something to hack on.