Request gitoid:sha1 and gitoid:sha256 as hash types for query api

There's a standing problem with folks using scanners to try to determine SBOMs. They produces lots of false positives. False positives lead to lots of wasted effort trying to rule out CVEs from those false positives. [OmniBOR](https://omnibor.io/) would allow capturing the precise artifact dependency graph from source files up. What would be needed to convert this into an SBOM would be the ability to map the hash of the 'leaves' (source files) to (component name, version, supplier) tuples. Naturally, [deps.dev](http://deps.dev/)'s query API looks like a great solution to that. OmniBOR uses gitoids as identifiers, because the most interesting artifacts in the artifact dependency graph, the leaf source code files, are typically stored in git, and indexed by gitoid.

Currently https://docs.deps.dev/api/v3alpha/#query supports many different hash types. This is good :)

It would be very useful if it could support Git Object IDs (gitoids) as a hash type.

Today git supports two kinds of gitoids - gitoid:sha1 and gitoid:sha256. gitoid:sha256 was recently introduced, with the option per repo to use it. As of yet it has seen little use. Therefore its important to support both gitoid:sha1 and gitoid:sha256

gitoid for blobs are easy to compute. You simply prepend the 'git object header' to the file contents and compute the hash (either sha1 or sha256) over the result. A 'git object header' for a blob is 'blob␣${size}\0'. Where '␣' represents the UTF-8 character 0x20 and '\0' represents the null character 0. ${size} is the number bytes of ${content} represented as a string base 10.

Simple golang gitoid computation code can be found [here](https://github.com/edwarnicke/gitoid) for reference. Further checks can be done using the [git hash-object](https://git-scm.com/docs/git-hash-object) command.