Add specialized components and port old components to new architecture

[Saethox]

Closes #80, closes #85.

Ported modules:

• archive
• custom_state
• generation
• initialization
• postprocess
• replacement
• selection
• termination

[Saethox]

The RandomSpread and RandomPermutation initializer and generation components were merged into a single component that implements Initialization and Generation and exposes these two different types with the new_init(population_size) and new_gen() methods, wrapping itself in an Initializer or Generator, respectively. The generator component replaces a population, while the initialization component generates a new one that is pushed on the stack.

I think this pattern is a reasonable compromise between code reuse and usability.

[Saethox]

Should the specialized component traits and helper structs rather be kept inside their respective modules? For example, Initialization and Initializor in operators::initialization?

Also, should we maybe split operators::generation into mutation and crossover/recombination submodules?

What do you think, @luleyleo?

[luleyleo]

Should the specialized component traits and helper structs rather be kept inside their respective modules? For example, Initialization and Initializor in operators::initialization?

I think that would be nice.

Also, should we maybe split operators::generation into mutation and crossover/recombination submodules?

Having submodules like operators::generation::mutation and the same for crossover seems reasonable, given how many there are. But the less classifiable should probably be kept in the operators::generation module.

[Saethox]

But the less classifiable should probably be kept in the operators::generation module.

Regarding this: PsoGeneration is currently located in this module, and I'm torn about this. On one hand, it kind of is a generation method, but on the other hand it is very heuristic-specific, with using a custom state and all. So I think it might be better to move it to heuristics::pso, similar to the ACO components. Or maybe add an operators::pso module? I think this is something we should discuss, as more and more heuristics with very specific components will be added in the future, which naturally don't fit into our previous categories.

[HeleNoir]

Regarding this: PsoGeneration...

I would like to keep it either as a kind of mutation or as some kind of operator::swarm. mutation would be suitable as the two operator types do essentially the same thing and should be interchangable in all algorithms. operator::swarm could be an alternative, as there are more PSO-like metaheuristics on our list and they do have very similar operators (this is also the reason why heuristics::pso would make the operator far too specific and I would say it isn't).

[Saethox]

This has become a very large PR, with more than 4000 lines changed, but I think this is appropriate.

• All relevant components were ported.
• The heuristic definitions were updated.
• Bugs were fixed (see Is this implementation correct? #85)
• Some postprocessing components were not updated, as they will be part of Rework logging #88
• Legacy code was not removed (see Remove legacy code #89)

@HeleNoir Please have a look especially at generation::swarm::PsoGeneration and the components in selection, and verify their correctness.
The selection::Tournament was sorting its tournaments the wrong way, and selection::LinearRank and selection::ExponentialRank did some weird thing with indirect rankings, which was very hard to understand, and I think incorrect. The ranking is now obtained by using argsort two times (which I'm still amazed that this works) and the layer of indirection was removed. I looked at a paper describing the exponential ranking, and it should now be correct. Applying the components in the GA also yields good solutions now, which was not the case before.

@luleyleo, I briefly looked at #88 and I think we have some overlapping functionality. I think a rebase of your branch would be good after we have sorted out this PR.

[HeleNoir]

I can't find any other issues (but I'm not that well-versed in Rust), so we should wait for @luleyleo to approve as well.

[luleyleo]

Looks great overall. A few nits to pick and then we can merge this.

[luleyleo]

Looks all good now 👍🏻