Introduce the theme-engine protocol

[PuercoPop]

The goal of this protocol is to allow users to customize what templates their themes use. Introduce a new generic function GET-THEME-FN and make COMPILE-THEME a generic function as well. Move all the cl-closure template specific code to closure-template-engine

A thing I'm unsure of is if using keywords for template engines is good enough or if we should use the 'Class method' approach used by the document protocol? I'm inclined to go with the simpler approach for the time being.

@libre-man I would appreciate your feedback on the API, which is a subset of your PR. Is the documentation understandable? Do you think something is missing?

Note that I intend to merge against the 0.9.8 branch, The idea is to get your PR and #115 merged and do some light testing before merging on the master branch and release a new version of Coleslaw

[PuercoPop]

Ok, after adapting the djula theme engine to this protocol I found a couple of issues

• template-engine should be part of the protocol. It allows us to keep the code agnostic to the template engine.
• get-theme-fn, compile-theme and template-engine should be exported. Also theme-fn should be removed from the exported symbols as it is now specific to the closure engine and will be moved to a plugin.
• There were uses of theme-fn in the main code base and plugins that had to be updated to use get-theme-fn instead.
• The &optional package argument of get-theme-fn should ideally be removed and moved to closure specific code. Don't really have a good idea of how to do so, so I'm leaving it as is.

[Ferada]

Regarding the package argument, the closure code also has it again in the called theme-fn as an optional argument - can't it be removed for good from the generic function then?

[PuercoPop]

@Ferada I think you are right, I'll look into it.

Btw, I've fixed the types noted in #120 thanks for catching them

[kingcons]

I imagine class methods aren't necessary here. Keyword specializers seem a bit more appropriate to me.

[libre-man]

Sorry that I was gone for sometime again. Is there something I can do to get this pull request further to acceptance?

[PuercoPop]

@libre-man I could merge this PR right away but I wanted to try out the suitability of the API by implementing djula as a plugin first. That is where I ran into trouble. The plugin mostly works but in order to make it work I would have to do away with djula's base template feature, one of its main selling points.

The blocker with the djula plugin is described in further detail here. The gist of it is that the rendering strategy of Coleslaw makes the assumption of 'nesting' templates (ie. having templates call other templates) instead of the djula approach of having a base layout and having templates extend it (which is a cleaner design imho fwiw). We need to find a way to abstract over that.