themes/simple/templates/index.html: Fix articles_page reference
generators: Add 'now' to the global context

It's often useful to know when the site was compiled.
generators: Try template name without .html extension first

Then fall back to the old .html extension.  This makes it possible to
include DIRECT_TEMPLATES that aren't HTML (e.g. iCalender files with
an .ics extension).
readers: Remove underscore to make METADATA_PROCESSORS public
readers: Only access METADATA_PROCESSORS once in Reader.process_metadata

This way we only have to look up the key once.
writer: Add ABSOLUTE_SITEURL to local template context

The current approach to relative/absolute URLs is with decorators
around the generator methods.  However, whether you actually need
absolute URLs probably depends on the template itself.  With this
patch we now have two context variables.  Use SITEURL where you want
to leave the relative-ness up to your Pelican configuration.  Use
ABSOLUTE_SITEURL when your template can't handle relative URLs.
generators: Cleanup *_SAVE_AS naming for direct templates

I have a `calendar.ics` template, and I don't want it to be saved as
`calendar.ics.html`.  However, I can't put:

  CALENDAR.ICS_SAVE_AS = 'calendar.ics'

in my Pelican configuration, due to the illegal `.`.  This commit
replaces some of these illegal characters (extend as necessary) with
underscores, so I can use:

  CALENDAR_ICS_SAVE_AS = 'calendar.ics'

Alternative approaches include:

1. Use the EXTRA_PATH_METADATA framework from readers.path_metadata.
   I didn't do this because it's possible that files in the content
   directory will have the same location as directly rendered
   templates.  Adding a new namespace under EXTRA_TEMPLATE_METADATA
   would work, although in either case you'd need a new
   DIRECT_TEMPLATE_SAVE_AS pattern to use the new metadata to
   construct the target filename.

2. Use the full source template filename, not the given name + '.html'
   when constructing the default target filename.  This would probably
   require altering Generator.get_template to return the successfully
   loaded name, unless that information is stored in the template
   instance itself (I'm not familiar enough with Jinja to know off the
   top of my head).  Check this before merging this branch.

While (2) would handle my particular case, adding something along the
lines of (1) would provide more flexibility to future users.  It's
probably a good idea to drop this patch and do both (1) and (2).
docs/getting_started.rst: Document HTML metadata format
readers: Use regexp groups to match HTML metadata

The new regexp is also more robust.  For example, it allows for colons
and non-ASCII characters in the value.
readers: Use pelican_open() in RawReader.read()

Assuming UTF-8 content is more consistent with existing Pelican code
(e.g. MarkdownReader.read()).
readers: Add JinjaReader for content written in Jinja

Metadata is extracted from JSON front matter when the page is loaded.
This approach was inspired by Jekyll's YAML front matter [1], but
takes advantage of the Python standard libraries JSON parser instead
of requiring the external PyYAML parser.

The page's template is expanded just before writing via a
Page.postprocess hook.  Readers that need this expansion can define
the hook, and read_file() attach it to the new content.  The hook is
run after |filename| replacement and other postprocessing already
handled by Page._update_content().  I expand the template just before
writing (rather than at read time), because the global context is
still being constructed at read time.

[1]: https://github.com/mojombo/jekyll/wiki/YAML-Front-Matter
WIP:settings: Expand EXTRA_TEMPLATE_PATHS relative to the config file

I suppose earlier versions of Pelican expected absolute paths, or
assumed that you'd run Pelican from the directory in which the config
file was located.

Conflicts:
	pelican/settings.py
    Conflict due to #661 fix in my WIP branch, but not in my #671
    branch.