Refactor MacOS implementation a lot

[Kijewski]

Cf. #64, #65.

[astraw]

@Kijewski I thought it was easier to read and safer if I moved each newtype to its own module. Along the way I did a small bit of refactoring. I have some concern this will not meet our MSRV requirements so may need to be updated once the CI tests are done. But it does actually run correctly on my Mac :)

[lopopolo]

This LGTM. I left one proposed tweak to break apart a gnarly conditional.

[astraw]

This looks good to me. Thanks @Kijewski for the main work here. And the CI tests do all pass.

It seems we have a consensus amongst committers/reviewers that this is ready to merge. However, as it carries the Unsafe-Proposed label, let's let this sit for a week (so, until 6 Oct) to attract review as discussed in #64. Also, if someone is auditing this crate (e.g. rust-secure-code/safety-dance#79 ), I ask them to please check this implementation as an alternative to the existing macOS implementation.

[lopopolo]

Thanks all! This looks like a big improvement.

[Kijewski]

I thought it was easier to read and safer if I moved each newtype to its own module.

I like that very much, @astraw. Now the types are truly self contained.

[astraw]

OK, as we changed the PR a bit with the new MSRV, keeping it open a week will now be 7 October.

[bjorn3]

I think this code doesn't have UB, but I do have a couple of suggestions to the safe code outside of system_time_zone and string_ref can't cause UB even when changing it.

(coming here from rust-secure-code/safety-dance#79)

[Kijewski]

Sorry, I caught Corona and don't think I'll be able to do any coding, commenting or reviewing until early next week. :/

[astraw]

The CI failures on the last commits here (archive member 'rust.metadata.bin' with length 4847795 is not mach-o or llvm bitcode file) seem unrelated to the changes made. They arise on macOS with rustc 1.38 but not current stable or nightly. For this reason I propose we ignore them, but I'm really not sure what is going on.

[astraw]

The test failures are now documented in #72, which is unrelated.

Thanks everyone for the feedback and especially @Kijewski for the work on this. I hope your recovery is well underway.