Lower the `_update_dict` into Cython (as close to C as possible). As the
big performance pieces are in the BLAS and not in this code, the main
objective here is to cutdown the amount of time not spent in those BLAS
functions as it can cause the BLAS to spin down its threadpool for
instance only to spin it up fractions of seconds later, which is quite
costly. This avoids that by calling directly into the BLAS C API with
contiguous arrays back to back. Only little bits of Cython are used to
string these together.

The GIL is released for the bulk of the computation. No-GIL operations
are employed where possible. This includes random number generation and
any array operations. The GIL is only released once and reacquired once.
Everything else that requires the GIL is moved outside that section and
information needed on the GIL side is passed from the No-GIL side. This
minimizes contention over the GIL with other processes.

Threading is maximized by using BLAS operations that will make the most
use of threads possible. Smaller BLAS operations are merged into larger
ones where possible. Wherever possible `for`-loops are converted into
some form of BLAS operation with the `for`-loop being pushed into BLAS.
This includes even simple things like find the sum of the residuals
squared or zeroing out arrays.

Arrays are coerced into contiguous form either by verifying that the
match the expected stride or copying them via NumPy if necessary.
Striding is employed to ensure movement along arrays in BLAS picks the
contiguous path as often as possible. This means arrays may be C or
Fortran order depending on what will be most efficient for fast
traversal and good use of the cache.

For convenience fused types are employed liberally including in binding
BLAS functions of different precision together. This makes it easy for
the same code to leverage single or double precision as needed with
minor specialization as required. Overall this makes for a nice blend of
static typing that remains relatively flexible.

Memoryviews are used heavily within functions and as part of the
definitions of all internal functions. Construction of memoryviews or
their slices is avoid as much as possible for performance reasons.
Instead direct indexing to a specific value or address location is
preferred wherever possible to maximize performance.

Function inlining is used heavily. Many of the functions have but a
couple lines or perhaps less. While convenient to have these as separate
functions for readability/comprehension, there is no point in taking a
hit on performance by having to perform a jump to get to these functions
when they are so simple.

To allow random numbers sampled from the normal distribution to be
generated without the GIL quickly, the Marsaglia polar method (an
optimization on the Box–Muller transform) is used. This is the same
method that NumPy's vendored copy of RandomKit uses. The performance of
our implementation ends up being notably faster than NumPy's. Though
doesn't appear to be surprising, it is a nice performance bump to have.

To simplify the code a bit and cutdown on repeated pointer arithmetic,
store frequently used addresses in memoryviews as pointers. This is
helpful for working with BLAS functions, which expect pointers as input.
Plus it ensures that we compute each address needed exactly once as
opposed to one or more times per BLAS function the address is needed
for. This also improves readability for developers as one can see that a
particular atom or sparse code is being used without having to think
about what the indexing means in each function. Also simplifies the C
code generated by Cython as it handles the pointer arithmetic once and
then simply uses the pointer in all other cases, which should make it
easier for the compiler to do its work and make it easier for developers
to reason about what is happening in the C code.

Borrow a trick from C++ to convert runtime checks into compile time
checks. The result being that a check that would have been run in the
tight loop of a function is made beforehand by dispatching a
specialization of the function that applies the result of the check in
its definition. Thus each check occurs only once at runtime before the
loops occur allowing the loops to remain tight and focused on only the
relevant steps. Programmatically the code reads similarly, which keeps
it in nice form for developers to work with.