consolegrl

@sakertooth @zonkmachine @Veratil have a look at this approach, if you like it I will move on to refactor and test the other routines.

As per @michaelgregorius suggestion in #6861 I have pushed a rough draft of a file-per-routine "Upgrade Routine Functor" restructuring as well as templates to assist others in writing upgrade routine...

> 2\. I'd rather they go into their own directory @Veratil what directory name would you prefer?

> Which this then opens up reorganizing the include directory into the same structure as src. That sounds...fun. Not difficult, but sounds frought with merge conflicts and stuff. ...Also don't...

Fun fact 2.b: It was so simple I figured it out on my own just poking around. just unfamiliar. > it will most definitely for any PR before that change...

@Veratil it is done. Now my new enemies shall emerge from the shadows and drag me down to Davy Jones.

> I always assumed that the root `include` directory was meant as the public interface to LMMS. I've only been with the project for a short time, [but I gotta...

> * Can we remove the `*.template` files? Some of the instructions seem off too (e.g., `LMMS_UPGRADEMIXERRENAME_H` should really be `LMMS_UPGRADE_MIXER_RENAME_H`) @sakertooth I think the templates will help other people...

@sakertooth @Veratil @michaelgregorius So the new method makes the order explicit, doesn't run any routines that don't need to be run (like the old way), uses simple templates, splits massive...

> * `DataFile::upgrade` will then "flatten" these `UpgradeContainer`'s, yielding something similar to the current `UPGRADE_METHODS` vector we have now. This function can then continue upgrading the project like before. This...