Improve performance of field_pretty for multiquadratic fields

[rvisser7]

This PR makes some improvements to the field_pretty function in web_number_field.py, which computes latex names for certain number fields. In particular, it makes computing the latex names for biquadratic and more general multi-quadratic fields slightly more efficient.

For quadratic fields, the computation of the $D$ in $Q(\sqrt{D})$ is now taken directly from the label (instead of calling WebNumberField), and the linear algebra for the multi-quadratic case is now done directly using bitwise XOR on integers (where we store a vector over F_2 just as a integer, where the bits are the entries of the vector), instead of calling Sage's general linear algebra methods.

The main motivation for this is to speed up the rendering time of the homepage for the degree 32 multi-quadratic field $Q(i, \sqrt{2}, \sqrt{3}, \sqrt{5}, \sqrt{7})$:

https://www.lmfdb.org/NumberField/32.0.4026692887688564776141139207792885760000000000000000.1 (prod)
https://beta.lmfdb.org/NumberField/32.0.4026692887688564776141139207792885760000000000000000.1 (beta)
http://localhost:37777/NumberField/32.0.4026692887688564776141139207792885760000000000000000.1 (new)

which requires computing not just the latex name for this field, but the latex name for all 372 subfields!

At the moment, this takes ~12 seconds to load on production, and ~8 seconds to load on beta, assuming the latex names haven't been cached yet. From my testing, this PR now takes ~4 seconds to load, before caching. But hopefully this will load even faster on beta. Still not ideal, but at least an improvement from the current implementation. :)

[edgarcosta]

From one of my best friends:

1. D is shadowed across two meanings (readability + latent fragility). At web_number_field.py:352, primes = ZZ(D).prime_divisors() relies on D still being the label discriminant string from line 224; six lines later for D in sorted_Ds: (line 358) rebinds D to a squarefree part. It's correct as written, but the correctness silently depends on the primes= line staying
   above the loop. The old Case 7 never referenced the label-D, so this coupling is new. Suggest disc = ZZ(D); primes = disc.prime_divisors() to decouple the names.

2. Behavior change in Case 5a (likely intended, worth confirming). The old code guarded with if not any(z._data is None for z in subs) — it only prettified biquadratic fields whose subfields exist in the DB, otherwise returning the raw label. The new code always computes from coefficients and returns the LaTeX form. This is more robust (the √D is purely arithmetic and
   doesn't need the subfields in the DB), but it does mean some labels that previously rendered raw will now render pretty. Confirm that's the desired outcome.

3. Discriminant factoring profile (minor, theoretical). prime_divisors() now factors the full field discriminant instead of the individual squarefree Dᵢ. For LMFDB's multiquadratic data the discriminant is smooth (small ramified primes), so this is fast — but for a hypothetical field whose generators are two distinct large primes sitting in different Dᵢ, factoring the
   product is harder than factoring each Dᵢ alone. Not a real concern given LMFDB's disc bounds + @cached_function, but the alternative (collect primes from the already-computed squarefree all_Ds) avoids any factoring regression for free.

[edgarcosta]

@rvisser7 Let me know what you think. Regardless, is an improvement, and I can also try to fix these issues.

[rvisser7]

Many thanks @edgarcosta for the feedback!

1. Thanks, you're right, the variable $D$ is being used for different things in the different cases. Since the logic for each case is mostly done separately, I didn't care too much about variable abuse between the different cases. As we already more often use the variable $D$ for the radical inside the square root $\sqrt{D}$ than the discriminant, I'm now using disc instead of $D$ for the actual absolute discriminant of the field K - thanks!

2. Yes, I think this is fine. We can easily compute the $D$ in $\mathbb{Q}(\sqrt{D})$ directly from the defining polynomial $x^2 + ax + b$ for any quadratic subfield, so I didn't think it was necessary to have to require that a multiquadratic K needs to have all its quadratic subfields in the database, in order give a pretty name for K.

3. Thanks for mentioning this. Although I'm not really convinced it'll be slower in practice to factorise the full field discriminant disc, as opposed to factoring each of the individual discriminants of the quadratic subfields of K ? E.g. even in the case of $\mathbb{Q}(\sqrt{p}, \sqrt{q})$, where $p$ and $q$ are two large primes, we'll still have the quadratic subfield $\mathbb{Q}(\sqrt{pq})$, and so the old code would still need to factorise the product $p*q$.

   If there's a particular example from the LMFDB you have in mind, I can compare and test the old and new code. Currently, it seems the largest biquadratic field in the LMFDB of the form $\mathbb{Q}(\sqrt{p}, \sqrt{q})$ for two primes $p, q$ is 4.0.281415789804304.1 which is $\mathbb{Q}(\sqrt{2027}, \sqrt{-2069})$. At least for me, the factorisation runs trivially fast either way, so I don't think this really matters.