Adds a base Fingerprint class that will be used as a fingerprint for Artifacts, Producer Versions, etc. Fingerprints are represented as an int64. When fingerprinting string content, we use the farmhash Fingerprint64 algorithm (via pyfarmhash), but convert the uint64 to int64 using two's compliment.

I also (went a little overboard and) added int64/uint64 types to enforce clear casting behavior + mypy static typing

Relates to #30 - I'll be adding the concrete use in Storage and Views in a follow up PR.

--

int64:

• Compact Storage: ✅
  • int64 should be much more compact than string, though that can be a fallback (eg: Javascript/JSON).
• Simple Combining Semantics (XOR): ✅
  • XOR is associative and commutative
• Datatype Portability: 📈
  • string > int64 > uint64
  • Databases: All database support string, most support int64, but a few key ones don't support uint64 (eg: postgres, dgraph, etc).
  • Languages: Most, but javascript/JSON are notable exceptions (BigNumber/json-bignumber or treat as strings).

Farmhash Fingerprint64:

• Speed to Compute: ✅
• Entropy: ✅
  • farmhash fingerprint64 should have enough entropy - not aiming for cryptographic hash accuracy here
• Implementation Portability: 📈
  • Packages in a handful of languages (orig C lib, python, Go, JS, etc) and databases (eg: BigQuery, Clickhouse).
  • Notably missing for:
    • Snowflake (they have a custom HASH/HASH_AGG, but perhaps we can request farmhash or add via a JS UDF)
    • Postgres

For systems that don't support farmhash, we can use an alternate mechanism (eg: Snowflake's HASH_AGG) with the caveat that content fingerprints won't be portable when/if changing storage/view.