Better handling of permutations of clusters in orbits

Once upon a time the sites of a clusters were permuted each and every time clusters were counted in the ClusterCounts class. Then, @angqvist found that performance-wise, it was a good idea to do these permutations during initialization of a ClusterExpansionCalculator, such that we don't need to do it before each calculation. After !514 (merged), it is mandatory to always do this permutation before counting clusters. Still, some remnants of the old approach have remained in the code and the permutations have occurred in scattered places throughout the code.

This MR lets the OrbitList handle permutations before an Orbit is initialized. In this way, Orbit does not need to know anything about permutations. This means that unless someone starts to create Orbits manually, the clusters will always be properly permuted.

Changes

• OrbitList does the permutations before initializing an Orbit, instead of adding information about the permutations to the Orbit after they are created.
• Orbit no longer knows anything about permutations
• The constructor of Orbit now takes more arguments than before, which (1) means that Orbits are usually fully functioning objects immediately after initialization, and (2) makes manual creation of Orbits more tedious, which is good because it shouldn't be done (except by tests)
• ClusterSpace and ClusterExpansionCalculator no longer need to bother about permutations.
• I made a few minor changes such as making _orbits a private member of OrbitList
• I had to rewrite a couple of tests since the Orbit constructor is changed
• I removed the Orbit benchmarking because I think they haven't been relevant for a while and they were quite complex

Consequences

• Fewer lines and IMO somewhat simpler logic in the C++ code
• A reduction with approx. 0-30 % in memory consumption during MC simulations (the reduction is more substantial with large supercells, we get it because we don't need to store information about permutations anymore)
• Approx. 5-20 % faster ClusterExpansionCalculator initialization
• A cluster vector change calculation (the most time-consuming part of an MC simulation) seems to be maybe 1-5 % slower on my Desktop, equally fast on my Mac, and 1-5 % faster faster on Vera. I suspect these differences are somehow related to memory managment; AFAICS I have not any changes that would have a direct impact on performance of MC simulations.

Closes #552 (closed)