analyze: borrowck: cache results of polonius runs on disk

[spernsteiner]

The Polonius stage of borrow checking takes a long time to run on certain functions, such as lighttpd's li_MD5Transform. Worse, we often run Polonius multiple times on the same function as the interprocedural analysis iterates to reach a fixpoint. This branch speeds up the analysis by caching Polonius results on disk.

The caching logic is fairly simple: the core Polonius analysis is effectively a pure function from input facts to output facts, so we hash the input facts before each call and check whether a file named after that hash is present in the cache directory. There's no need to factor in any details of the crate, MIR, permissions, etc. If the current Polonius query has the same input facts as a previous query, it will necessarily produce the same output facts, regardless of how those input facts were computed.

Computing the input facts still has a nontrivial cost for some functions, but this branch provides significant speedups on algo_md5 and lighttpd_rust_amalgamated once c2rust-analyze has run once to populate the cache.

[aneksteind]

why is a tuple needed for the serialization as opposed to serializing the struct directly?

[spernsteiner]

The struct is defined by the polonius crate and doesn't implement Serialize. Serde has some support for deriving impls for types in "remote crates", but it requires duplicating the struct definition and generally seems like a bit of a pain. Since we don't use the struct in fields of other Serialize types, we don't need a proper Serialize impl for it, and this tuple trick is sufficient.