Add point group representation theory functionality

This MR adds new features:

• PointGroup class to store point groups and their representations. It subclasses set, so should be backward compatible with current code where pointgroups are stored as simple sets of PointGroupElements.
• Add double group functionality to PointGroupElement, and implement phase fixing for the unitary parts.
• Implements Burnside's algorithm to efficiently construct all irreducible representations of any discrete group.
• Decomposition of the unitary representations into irreps.
• Find physical irreps, i.e. irreps compatible with time reversal symmetry. Incudes the case of magnetic point groups, where TR is not a symmetry, but the group includes symmetries that combine TR with a nontrivial point group element.

TODOs:

• Integrate with existing code, preferably in a backward-compatible fashion. symmetries currently returns a tuple of two sets corresponding to the discrete symmetries and continuous symmetries. I propose that we make a SymmetryGroup class subclassing tuple to store these, and a ContinuousGroup class subclassing set to store the continuous group generators. For now these would mostly just be placeholders, but in the future I would like to implement algorithms that handle cases whith both continuous and point group symmetries (the implemented algorithms ignore the continuous symmetries). As far as I see, the symmetry finder returns consistent discrete unitaries even when continuous symmetries are present, but I don't think this is guaranteed, requires testing. The hamiltonian generator algorithms only need to be modified slightly to take input in the new format as well.
• Handle antisymmetries (particle-hole and chiral) in PointGroup. Now antisymmetries are treated like symmetries, but in most applications of representation theory (such as finding protected degeneracies) they should be ignored, as they don't conserve energy. I suggest the default behaviour be raising an error if antisymmetries are present, and two other options being forcing to ignore them, or treating them like any other symmetry.
• Think about future-proofing the double group functionality of PointGroupElement, especially in the presence of both TR and PH symmetries. The problem is this: the double group is represented by not only storing the real space rotation R, but also a half-spin SU2 rotation matrix RSU2 in the group element, this way it is possible to keep track of 2pi rotations, where RSU2 = -1, distinguishing it from the identity (denoted d1 in the crystallograpy literature). Usually, when TR is also present in a spin-1/2 system, it can be represented as σ_y K in the SU2 rotation space, this commutes with every rotation and squares to -1, i.e. the d1 group element. But I don't think that in general full rotation and TR^2 has to be the same, they can independently be ±1. That is why I decided to not go with RSU2 = σ_y K for the TR operator, instead implemented a logic where the sign of TR^2 is stored in the conjugate attribute. However, if PH is also present, it could also independently square to ±1, and I don't think the current structure can keep track of two antiunitaries squaring to different values (this case requires a chiral operator which multiplied with an antiunitary switches whether it squares to +1 or -1). Currently RSU2 is not necessarily 2x2, and all AZ classes could be represented using 4x4 matrices, but this would complicate things in the most common cases. In summary, we need to think this through carefully before committing to this implementation.
• Add more tests, rewrite the existing tests and tutorials to use the new functionality.