Refactor BlacklightHelper into a DocumentPresenter. Fixes #782

[jcoyne]

No description provided.

[jcoyne]

This could look a lot nicer if it weren't for this commit: 855bec1 which introduced a document argument to some of the helpers. @cbeer do you remember why that was necessary?

[cbeer]

I think I like it. I also like we didn't have to drag in draper or something pretty heavy-weight (although it looks like it'd be easy enough to use draper if you wanted, right?)

The document argument is an extension point for applications to make document-specific decisions about (generally) configuration. So, you might have one set of fields to render if your document is an X, but a completely different set if it is a Y. From #523:

Update index_field and document_show_field (and similar) methods to support an optional 'document' argument, which may be used downstream to inject alternative index/show fields based on characteristics of a document.

[jrochkind]

I like providing a way to make document-specific decisions about things. Including hetereogenous documents in the same result set, that should potentially be displayed differently, is a key use case for us (even though we haven't really gotten around to doing it yet, it's always been part of our interest in BL).

[cbeer]

@jcoyne what gets better if we don't have that optional document argument? Should we merge this now and make it better later, or is there something we could do now to make it closer to the ideal?

[jcoyne]

Merge now. We can refine further later. The improvement I had in mind would just be to do a straight delegation to the presenter, rather than making a new presenter for each call to the methods in BlacklightHelper.