WIP / DNM: native counter-based random number generators

[rileyjmurray]

This PR is a work in progress.

Summary

• removes RandBLAS's dependency on Random123 (source, package, CI, and installed-package);
• provides native, header-only Philox engines with static known-answer tests;
• introduces the concrete RNGState<Engine> adapter and structural GeneratorState customization boundary;
• provides RepackedOutput for power-of-two output-word subdivision; and
• preserves coordinate-addressed, thread-count-independent sampling.

The default Philox<4, 32, 10> integer stream and default sparse-sketch output remain bitwise compatible with the previous Random123-backed implementation. Dense transforms retain the same formulas subject to host math-library rounding.

Validation

The branch includes Philox known-answer tests, counter/repacking/transform unit tests, statistical tests, sampler regression tests, installed downstream and example builds, and clean builds with Random123 discovery disabled.

Deferred optimization opportunities

This PR uses portable implementations and intentionally defers architecture/compiler-specific tuning. Follow-up performance work could evaluate:

• dedicated 64-bit multiply-high instructions or newer compiler builtins in Philox's mulhilo path;
• compiler-specific unrolling or vectorization pragmas for Philox rounds and repacked-output loops; and
• SIMD implementations of result-block floating-point transforms.

These changes should be benchmarked by compiler and architecture before they replace the portable code.

[rileyjmurray]

Various notes:

The underlying Engine's generate function shouldn't return a separate output array, it should write to a provided input array.

We should include at least one modern (post Random123) CBRNG in the this PR. It's worth doing that at as part of the monolithic change since that might affect API design.

We'll need implementation DevNotes before the merge.

The plan (not kept in tree long term) should indicate how our base random number generators compare to the tooling in the C++ STL.

Before starting serious implementation we need to discuss what C++ idioms might be used and why.

[rileyjmurray]

Ping @vasilisge0

[rileyjmurray]

@vasilisge0, I'm having codex start implementation work now.

[rileyjmurray]

Here are comments that apply across multiple files.

• The copyright statement for Random123-derived files needs amending.
• The PR description (when written) should flag parts of the code that would benefit from machine-specific instructions or compiler pragmas for more up-to-date compilers.
• We need to talk about the use of the class and private keywords in new data structures.
• Don't be so paranoid about line length. Screens are big these days.
• We need to acknowledge the role of CBRNGStream. It's weird that it's only in sparse_data.hh. (I remember putting it here, so it's my fault, but it's nevertheless weird.)
• I'd like to change templating expressions like RandBLAS::CounterBasedRNGState State = RandBLAS::DefaultRNGState to CounterBasedRNGState state_t = DefaultRNGState; the in-library RandBLAS:: qualification shouldn't be necessary. Separately, I prefer that the state type be referred to as state_t rather than State.
• Let's just rename RandBLAS::CounterBasedRNGState to RandBLAS::RNGState. All of our RNGs will (always) be counter-based. (Please amend the comments above appropriately given this expression of preference.)

[rileyjmurray]

idea: have counter arrays support an incr_by_product function that accepts an iterable of int64_t and performs the correct unsigned-integer increment for the product of the iterable's contents without risking overflow of int64_t.