Allow dynamic PJAX type change when building a HTTPResponse

[mateusz]

Previous approach as done in #464 is not very clean. I don't entirely like this (more discussion in #472), so here is I think a better approach, that allows dynamic modification of the response at the end of the control flow.

It also removes the problem of changing the FormAction API, puts PJAX related stuff into PJAX related class, and removes the css class dependency.

[chillu]

Hey Mateusz, I think Sam was referring to an overridden X-Pjax in the response headers, rather than the request. I've solved it through this custom header, rather than an explicit override property on the handler, but kept your logic in principle. One assumption that we're still making is that the returned content still replaces the same selector. So in the case of deleting a ModelAdmin record, that's '.cms-edit-form', which happens to work for both X-Pjax=Content and X-Pjax=CurrentForm. We could override an X-Pjax-Selector the same way of course, but I'd rather not encode these templating assumptions in controllers, too much coupling. Haven't come across this situation yet. If we do, I'd suggest that we implement a "hard redirect" setting in the response headers, which acts conservatively and refreshes the whole window via document.location.

See 5b03f49. By the way, I'm also looking into handling multiple Pjax fragments in the response, which will further complicate these edge cases sigh http://open.silverstripe.org/ticket/7176