Implement a way to specify the output order of individuals in forge

[nevrome]

@AyGhal and I realized that it would be very helpful if one could set the output order of individuals in forge.

Currently the order depends on the order in which packages/data are discovered by -d and -p. This is not ideal.

Maybe this could be implemented by considering the entity order in the --forgeString DSL.

[stschiff]

In full generality, this would require a complete rewrite of how we currently read the forge DSL. With the recent additions implemented in #211 I must admit I'm tempted to actually do this. We started off with this cool idea of identifying forge-samples with a single-pass through the individuals-list. This is clever and fast, but it also means that the output order will always be determined by the input order.

If we want the output-order to follow the forge-file, then we need to switch from our current algorithm to a kitchen-chef-algorithm. Meaning that instead of going through the individuals-list and choosing what's in the forge-file, we need to go through the forge-file instead and choose from the individuals whatever is needed.

I think this will technically be slower (because usually the individuals-list will be much longer than the forge-list), but perhaps only virtually so, since this is all super-fast on today's CPUs.

So technically, it's a simple algorithm:

for each forge_item in forge_list; do
   if(forge_item is an Addition)
       go through individuals-list and select out the items that match the forge_item
   else # Subtraction
       go through the already constructed list and remove everything that matches the forge_item.
done

So in Haskell, I think this would necessitate stateful operations, using a State-Monad. I've done that before, it's very easy. And it could then also make the code added in #211 quite a bit simpler, too.

[nevrome]

Phew... I would prefer not to rework this crucial code yet again, especially as it's relatively well tested now and more pressing tasks are at hand. I'm also not convinced yet that a full rewrite is necessary.

Maybe some changes to the entity extraction algorithm in and around conformingEntityIndices would already be sufficient.

[stschiff]

I would welcome that change at some point in the future, and I would volunteer to do a rework. I think already with the new priority syntax, the old single-pass code has become difficult to read and maintain and I would anyway prefer a kitchen-chef algorithm. But I admit that it's something for the future.

[stschiff]

I would now revive this issue, as it will become easier to implement once #268 is merged. Let's pick it up from there.