content: Convert StaticContent.filepath to .filename

For reasons that are unclear to me, StaticContent introduces the
`filepath` attribute rather than using the existing (and semantically
equivalent) Page.filename.  This has caused confusion before [1], and
it's probably a good idea to merge the two.

[1]: https://github.com/getpelican/pelican/issues/162#issuecomment-3000363
content: Convert Path.filename to .source_path

Making everything consistent is a bit awkward, since this is a
commonly used attribute, but I've done my best.

Reasons for not consolidating on `filename`:

* It is often used for the "basename" (last component in the path).
  Using `source_path` makes it clear that this attribute can contain
  multiple components.

Reasons for not consolidating on `filepath`:

* It is barely used in the Pelican source, and therefore easy to
  change.
* `path` is more Pythonic.  The only place `filepath` ever show up in
  the documentation for `os`, `os.path`, and `shutil` is in the
  `os.path.relpath` documentation [1].

Reasons for not consolidating on `path`:

* The Page elements have both a source (this attribute) and a
  destination (.save_as).  To avoid confusion for developers not aware
  of this, make it painfully obvious that this attribute is for the
  source.  Explicit is better than implicit ;).

[1]: http://docs.python.org/2/library/os.path.html#os.path.relpath
doc: convert Markdown example to source_path and modernize
tests: Update tests after filename/filepath -> source_path
utils: Add deprecated_attribute decorator
contents: Add deprecation warnings for Page.filename and StaticContent.filepath
generators: Teach Generator.get_files to handle non-directory input

This makes it easier for StaticGenerator to walk FILES_TO_COPY, where
the input may be a directory or a bare filename.

Non-traversable file types (e.g. everything but directories and
symlinks to directories) are not checked against the exclude list.
The user-level effect of this is that explicit entries in STATIC_PATHS
or FILES_TO_COPY will override a hypothetical STATIC_EXCLUDES setting,
which seems like a reasonable approach.
contents: Convert StaticContent to Content, a Page subclass

Content needs a lot of the same handling as other pages, so make it a
subclass of Page.  The rename from StaticContent to Content make for
cleaner configuration settings (STATIC_URL instead of
STATICCONTENTURL).

All currently generated Static instances override the save_as
attribute explicitly on initialization, but it isn't hard to imagine
wanting to adjust STATIC file output based on metadata (e.g. extracted
from their source filename).  With this union, the framework for
manipulating URLs and filenames is shared between all source file
types.
readers: Split parse_path_metadata from read_file

For easier re-use.  I also extract the path metadata first, so
metadata explicitly listed in the file contents will take precedence
over metadata parsed from the filename.
Add the PATH_METADATA setting

Sometimes the base filename doesn't have everything you need.

Remember that os.sep is platform dependent, so using it in a regular
expression for this setting may not be portable (boo MS Windows!).
Replace os.sep.join with the more robust os.path

From the Python docs for os.sep [1]:

  Note that knowing this is not sufficient to be able to parse or
  concatenate pathnames - use os.path.split() and os.path.join()...

Where I touched a line, I also changed double quoted string literals
to single quotes, since they are used more often in the source:

  $ git grep '"' pelican/ | wc -l
  506
  $ git grep "'" pelican/ | wc -l
  1016

[1]: http://docs.python.org/2/library/os.html#os.sep
settings: Use splitext to remove extensions, not rpartition
Convert '.' and '..' to the less magical os.curdir and os.pardir

While I'm cleaning up path manipulation, I might as well make things
more semantic.
contents: Add URLWrapper.__repr__
readers: Add 'static' to the base Reader's extensions

Instead of just being a base class, we can use it to parse static
files.  It won't actually do any parsing, but we will get path
metadata extraction from read_file, and this will make the
StaticGenerator implementation simpler.
generators: Use the static format to read Static metadata

This cuts down on the remaining difference between static files and
articles/pages.
readers: Instrument read_file to return context objects
signals: Sort signals into categories
signals: Add missing signals

Note that the `pages_*` names are plural , while the `article_*` names
are singular.  I'll fix this once I update the PagesGenerator.
Move Article metadata extraction from generators to readers

There's no reason why this information should be Article-specific.

This commit breaks the other generators for the moment.  I'll fix them
shortly.