Generate context objects in read_file()

This pulls commits 1ad4afc through c0a4a50 off of #671.  All of the
earlier #671 work is already in `master`, so this shoul be ready to
go once we deal with any internal issues.

The assorted generators all use `read_file()` to read in the file
contents and metadata.  Previously, they sometimes parse additional
metadata, fire off signals, and initialize a `pelican.context.Content`
subclass on their own.  Reduce duplicated code and increase
consistency by shifting all that stuff into `read_file()` itself.

The tricky part here is that this makes some backwards incompatible
changes in the name of consistency.  For example, a goodly number of
signals were renamed to standardize on `*_generator_*` instead of
`*_generate_*`.  I haven't gone through and added formal deprecation
support for these changes yet (a la `deprecated_attribute`), but it
should be possible to work something like that up if folks feel it is
very important.

`FILES_TO_COPY` has also been replaced with the more general
`EXTRA_PATH_METADATA` and the artificial `static/` path's are gone.  I
think this is an incredibly useful change (arbitrary metadata for
static content!  Consistent metadata extraction!), but it is a major
shift.  It's harder to keep backwards compatibility here without some
really ugly conditionals.

Finally, there are a largish number of commits in this pull request,
since my approach was to make the fundamental shifts, and then
gradually clean up the bits that were newly broken.  I think this
makes for more understandable commits, but I'd be willing to squash
things together if others feel like that would make things clearer.
The best way to simplify would be to split this into
sub-pull-requests, but I couldn't find any good lines for breaking
this one up.