Reapply "BREAKING: Make random_mod platform-independent"

[mrdomino]

This reverts #1017, reapplying #1010. See also: #1018 (comment).

It turns out that the previous approach ran afoul of a likely LLVM (or possibly rustc) bug.

This time, I tried removing random_mod_core entirely and instead writing random_mod and try_random_mod as rejection loops over random_bits and try_random_bits. It is a little unfortunate that we write the rejection loop three times, but somehow, this does not (seem to) run afoul of the bug.

[codecov]

Codecov Report

❌ Patch coverage is 76.19048% with 10 lines in your changes missing coverage. Please review.
✅ Project coverage is 79.85%. Comparing base (e9f0efd) to head (de1e6b6).

Files with missing lines	Patch %	Lines
src/uint/rand.rs	74.19%	8 Missing ⚠️
src/uint/boxed/rand.rs	81.81%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1020      +/-   ##
==========================================
- Coverage   79.86%   79.85%   -0.02%     
==========================================
  Files         163      163              
  Lines       17737    17736       -1     
==========================================
- Hits        14166    14163       -3     
- Misses       3571     3573       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[mrdomino]

@tarcieri WDYT? I could go either way on this personally; it does seem a bit of a shame to lose random_mod_core. (I’d initially forgotten about BoxedUint when writing this.)

[mrdomino]

(fyi #1009)

I don't think I like this approach. With that bug lurking and the BoxedUint loop untested, this could still hang in some cases; I don't know why it doesn't.