Add assertions to make it easier to debug plugin configuration.

[dwt]

Since this cost me two hours yesterday configuring the plugin for the first time, I figured that others will have the same problem.

What did I do: I added assertions so the plugin will fail loudly instead of silently when it's configuration doesn't agree with what it gets tasked with creating a url for.

I am not quite sure if this is the best way: I am thinking that it may be better to get rid of many of the configuration values and instead replace them with a dynamic configuration in the way it's virtual resources are called.

I.e. if I call the plugin with /blog@atom/main, then I think it entirely reasonable, that the url of the feed is auto generated at /blog/atom_main.xml (or something similar) and that it takes in all blog posts below /blog/. But thats something for another day perhaps.

[goanpeca]

@nixjdm what do you think of this? How should we "standarize" to signal problems on plugin. Printing out to the stdout, or implementing assertions? or ?

[nixjdm]

Failing silently is rarely a good thing. Using assertions is a great way to make an problem obvious so it can be easier to debug. When you're configuring a plugin or project, I can't foresee a time when you'd want to ignore the problem or find out about it subtly. I think throwing errors on this sort of thing is a sensible default.

[nixjdm]

@goanpeca I just resolved the conflicts so this is ready again for review.