Build intrinsic archive sum

Summary:
# Problem

Oddly enough, since the addition of ReactiveCocoa to Electron on MacOS, we're seeing non-determinism when creating tar archives. P144049799 shows the difference between two release artifacts built on Sandcastle. Their contents are identical but they're packed differently.

# Approach

To counter this, I'm now calculating the checksum not based on the archive itself but on its *sorted* contents by first inserting all files into a `BTreeMap` with the file path as key and then lastly hashing all hashes, building some sort of bastardised Merkle tree.

# This diff

I'm only implementing the hashing here. The next diff will actually make use of this.

# Further steps

This requires a few more downstream changes which will require some finesse to roll out.

- The manifest will need to include both the intrinsic and extrinsic checksums as Launcher depends on the latter to verify the download integrity. We could also calculate the intrinsic checksum again, but that just adds more complexity which is hard to debug.
- Sandcastle will need to understand the new manifest format and we need to schedule the MSDK rollout accordingly. Not a huge problem as the call volume is low and manual.
- We need to modify the artifact and release ents to contain both checksums.
- The release endpoint needs to be modified to return the checksum the launcher cares about.

Reviewed By: nikoant

Differential Revision: D24024011

fbshipit-source-id: 55de748178c033c18a69c79c68f12e7c1aaf4deb

packer/src/main.rs

@@ -14,6 +14,7 @@
 )]
 
 mod error;
+mod tarsum;
 mod types;
 
 use anyhow::{bail, Context, Result};