RFC: Split `sign.c` into sign/verify/keygen logic

[hanno-becker]

Some consumers may only be interested in a subset of sign / verify / key generation. While we can consider adding configuration options for disabling them at compile time, that is only half-satisfactory for those consumers because they would either need to a) take the whole sign.c and accept dead code in it, b) manually simplify sign.c, throwing out the code they don't need.

It would be more convenient if sign/key and verify would be in separate compilation units, so that a consumer merely interested in verification could just drop sign.* from the import.

Happy about thoughts @mkannwischer

[mkannwischer]

There are a lot of functions in polyvec.c/poly.c/poly_kl.c/packing.c that are only required for a subset of keypair/sign/verify.
So if you really want to split by compilation units, you will either have to split them as well or turn them into headers and make everything static. The former seems inconvenient for consumers. Do we foresee any larger issues with the latter?
In that case we would only have 3 C files: keypair.c/sign.c/verify.c (+the ct.c) - everything else would be headers.