Refactor admin view functions to allow for easier overrides

[Adam Venturella]

Currently the admin views hosted in django.contrib.admin.options are pretty monolithic in their implementation. That's not necessarily a bad thing until a user needs to override only a portion of the view logic. In which case the whole view function needs to be overridden which is not ideal as that overridden view now needs to keep pace with any changes in Django releases.

This ticket proposes enhancing the various admin views to begin to allow some designated, override points, for example, modify the context or placing the TemplateResponse into a separate function.

Modify the context after it's been generated could be something like:

# changelist_view
context = self.update_changelist_view_context(request, context)

#delete_view
context = self.update_delete_view_context(request, context)

These could initially just be a noop, but a user would be able to easily add additional information or make modifications if necessary.

Similarly, moving the TemplateResponse's into functions would also allow for cleaner composition when creating new view handling overrides, for example:

self.render_changelist_view_template(
    request,
    default=self.change_list_template, 
    app_label=app_label,
    model_name=opts.model_name,
    context=context
)

This would obviously not address all potential enhancements, but things gotta start somewhere.

[Tim Graham]

It would probably be best to do this part of a conversion to class-based views (#17208).