Define page templates and layout parts in dedicated Ruby files

[simmerz]

Theme initializers had grown into long lists of parts and view templates that were hard to read and painful to maintain. This moves those definitions into app/templates/spina/{theme}/, one file per page template plus an optional layout.rb for site-wide parts. PageTemplate.define and LayoutParts.define provide a small DSL for declaring parts and repeaters. Built-in part types use symbols; custom parts keep their full class name as a string. At boot, Spina compiles these files into the same structures the admin already expects, so the rest of the engine stays largely unchanged.

Part definitions are scoped to their template (and separately for layout), so the same name can mean different things in different places without conflict. The old theme.parts and theme.view_templates configuration still works for now, with a deprecation warning and a spina:theme:migrate_templates task to convert existing themes. The migrator backs up the original initializer as .rb.bak so Rails won't load it.

The install generator and dummy app are updated to use the new layout.

[Bramjetten]

Woah, that’s a lot of changes!

[simmerz]

It needed a bit to change how the parts worked - when I got into it, I realised we needed to solve for conflicts in naming where two pages or the layout have parts with the same name - those shouldn't matter and should work, but wouldn't have.

[wakproductions]

Sheeeeesh! This is a significant change. I like the idea of the abstractions. I think this is a very difficult program to work on architecturally as is. It's hard for me to tell right now as so much of this I still haven't figured out, but I hope that this new organization for the page template metadata will make it easier to contribute new modules to Spina.