Add O_K generators for monogenic number fields

[rvisser7]

For number fields $K$ which are monogenic (i.e. where the ring of integers $\mathcal{O}_K$ equals $\mathbb{Z}[\alpha]$ for some $\alpha \in \mathcal{O}_K$), I think it would be very useful to store an explicit element $\alpha \in O_K$ which generates $O_K$. There are some monogenic fields where the root $a$ of the standard defining polynomial given by pari's' polredabs is also a generator for $O_K$, but there are many monogenic fields of degree $\geq 3$ where this is not the case - here are some examples: 3.1.244.1, 3.1.356.1, 3.1.424.1, 4.0.1040.2, 4.0.1413.1, 4.2.2092.1

One option is to store $\alpha$ as an integral combination of the current integral basis for $O_K$, or alternatively store a minimal polynomial for such $\alpha$ (both would involve storing just a list of $[K : \mathbb{Q}]$ integers, so would probably take up a similar amount of space).

[roed314]

Great point. I can see arguments in favor of both approaches for storing α: we normally store everything in terms of our fixed polredabs defining polynomial, but monogenicity is something that privileges another choice of defining polynomial, so it's somewhat natural to store that other choice. Algorithmically, it's not very hard to go from one to the other for number fields like those in the LMFDB, though minimal polynomial is easier than root finding in general.

[jwj61]

If you are going to do this, I would do just the coefficients of defining polynomials. Since this is probably a small percentage of all number fields, it may be better to make a separate table.

[roed314]

In terms of storage space, a column that is null takes very little space. Since we're not searching on it, it can go in the extras table (ideally I will switch from the extras table to a new separate table beforehand)