Use usize for cache keys instead of u64.

[xorgy]

This improves portability, because AtomicUsize is available on 32-bit targets, but generally AtomicU64 is not.

[xorgy]

From a safety perspective, I think it's much more likely we run out of memory in a 32-bit process, than exhaust usize font IDs or cache keys, so I don't see this being an issue.
Please don't try to load four billion fonts on a Raspberry Pi 2, and then file an issue about it...

[dfrg]

I’m happy to use an AtomicUsize counter to better support 32-bit targets but I’d prefer to keep the rest of the API the same to avoid breakage. In particular, the [u64; 2] key type is used by parley to store blob ids from peniko. Not ideal and I think we can do better but that’s future work.

[xorgy]

I can separate the two until we look at a break.

[xorgy]

I've put up #70 for this non-breaking subset. @dfrg

[xStrom]

As main already contains breaking changes, the next Swash release will be breaking anyway. In that light I think including more breaking changes right now makes sense.

Is the Parley/Peniko situation a hard blocker that must be solved first, or can Swash lead the way here?