_layouts/base.html: simplify by factoring out HTML blobs

Jekyll uses Liquid templates, which make it difficult to stack
templates.  This patch breaks the content of the base template up into
manageable, reusable bits.
index.html: automate map creation in _layouts/mapcal.html

Use the Google Maps JavaScript API v3 [1].  Boot camp posts should
define a `latlng` value in their YAML front matter to get a pin on the
map.

[1]: https://developers.google.com/maps/documentation/javascript/
_includes/map-header.html: remove unneeded viewport meta

I'm not sure which map example I grabbed this from, but the map works
fine without it.
_layouts/mapcal.html: rename "initialize" -> "initialize_map"

This will let us write up other javascript blobs
(e.g. "initialize_calendar") without competing for generic function
names.
_layouts/mapcal.html: move map JavaScript import into the footer

This helps the page load faster, since the non-map portions of the
page can render while the JavaScript library is downloading.
_layouts/mapcal.html: Embed a Google Calender

The Google Calendar should be automatically populated by the iCalendar
boot-camps.ics feed, which we don't generate (yet).

Incidental changes:
* Make the map a bit wider, because there's only so far you can
  scrunch the calendar before things start going wonky, and it's nice
  to have both the map and the calendar be the same width.
boot-camps.ics: Add template for Jekyll-generated iCalendar output

Create an iCalendar (RFC 5545) with event info for each boot camp.
This requires the following new YAML front matter fields:

  timestamp: the date on which the event was last modified (for
    DTSTAMP)
  end: the date when the event ends (for DTEND)

It also takes advantage of the existing `time`, which it uses for
DTSTART.  Both of these dates should be in ISO 8601 format
(YYYY-MM-DDThh:mm:ssTZD), but any timezone data given in TZD is
ignored, and the time is interpreted as UTC.  If Liquid's `date`
filter could convert input timestamps to UTC, we would have more
flexibility here, but it can't, and RFC 5545 requires UTC times for
some fields (e.g. DTSTAMP, see section 3.8.7.2).  Because of the
timezone issues, you should probably just stick to YYYY-MM-DD format,
and leave the time unspecified.

Here's the description of timestamp/DTSTAMP from RFC 5545:

   3.8.7.2. Date-Time Stamp
   Property Name:  DTSTAMP
   Purpose: ...In the case of an iCalendar object that doesn't specify
      a "METHOD" property, this property specifies the date and time
      that the information associated with the calendar component was
      last revised in the calendar store.

In principle, this could also be generated from the VCS log of the
post itself, but we are limited to what we can accomplish in pure
Liquid.
boot-camps.ics: Add a LOCATION field holding the `venue` metadata

One of the examples from RFC 5545 section 3.8.1.7 is:

  LOCATION:Conference Room - F123\, Bldg. 002

so our values should be acceptable.
boot-camps.ics: Add a GEO field holding the `latlng` metadata

The geographic position described in RFC 5545 section 3.8.1.6 requires
a semicolon separator, so convert from our internal comma separator.
2011-11-07-toronto: fill in YAML front matter timing data

These fields are used to create the Liquid iCalendar output.
boot-camp.ics: Restrict DTSTART and DTEND to date precision

Drop the time portion of the events, which people should find from the
details on the boot camp page itself.  Also drop the timezone
specification, which will leave the times "floating".  From RFC 5545,
section 3.3.5:

  FORM #1: DATE WITH LOCAL TIME

  The date with local time form is simply a DATE-TIME value that does
  not contain the UTC designator nor does it reference a time zone.
  For example, the following represents January 18, 1998, at 11 PM:

    19980118T230000

  DATE-TIME values of this type are said to be "floating" and are not
  bound to any time zone in particular.  They are used to represent
  the same hour, minute, and second value regardless of which time
  zone is currently being observed.  For example, an event can be
  defined that indicates that an individual will be busy from 11:00 AM
  to 1:00 PM every day, no matter which time zone the person is in.
  In these cases, a local time can be specified.  The recipient of an
  iCalendar object with a property value consisting of a local time,
  without any relative time zone information, SHOULD interpret the
  value as being fixed to whatever time zone the "ATTENDEE" is in at
  any given moment.  This means that two "Attendees", in different
  time zones, receiving the same event definition as a floating time,
  may be participating in the event at different actual times.
  Floating time SHOULD only be used where that is the reasonable
  behavior.
boot-camps.ics: Use site.time to generate DTSTAMP

This means that the timestamp will change after every site rebuild,
even if the data for a particular boot camp hasn't changed.  Hopefully
that doesn't cause a problem for consumers.
boot-camps.ics: Add DESCRIPTION with an ALTREP link to each boot camp

I changed the `host` in _config.yml to get valid links.  If this moves
to swcarpentry.github.com, we'll have to adjust the link again.
boot-camps.ics: Use DURATION instead of DTEND

The previous DTEND implementation was wrong, because DTEND should have
marked the day after the event ended.  From RFC 5545, section 3.6.1:

  The "DTEND" property for a "VEVENT" calendar component specifies the
  non-inclusive end of the event.

Rather than fixing that, use the DURATION property instead.  From
section 3.8.2.5:

   Property Name:  DURATION
   Purpose:  This property specifies a positive duration of time.
   Description:  In a "VEVENT" calendar component the property may be
      used to specify a duration of the event, instead of an explicit
      end DATE-TIME...
      When the "DURATION" property relates to a "DTSTART" property
      that is specified as a DATE value, then the "DURATION" property
      MUST be specified as a "dur-day" or "dur-week" value.
boot-camps.ics: Specify VALUE=DATE for DTSTART

From the examples in RFC 5545, section 3.6.1:

  DTSTART;VALUE=DATE:19971102

So let's specify that our DTSTART lacks any time information.
boot-camps.ics: Escape special characters in SUMMARY

From RFC 5545, section 3.3.11:

  The "TEXT" property values may also contain special characters that
  are used to signify delimiters, such as a COMMA character for lists
  of values or a SEMICOLON character for structured values.  In order
  to support the inclusion of these special characters in "TEXT"
  property values, they MUST be escaped with a BACKSLASH character.  A
  BACKSLASH character in a "TEXT" property value MUST be escaped with
  another BACKSLASH character.  A COMMA character in a "TEXT" property
  value MUST be escaped with a BACKSLASH character.  A SEMICOLON
  character in a "TEXT" property value MUST be escaped with a
  BACKSLASH character.  However, a COLON character in a "TEXT"
  property value SHALL NOT be escaped with a BACKSLASH character.

I don't escape newlines, because summaries in the YAML front matter
should only be one line long.
boot-camps.ics: Use CRLF line separators

From RFC 5545, section 3.1:

  The iCalendar object is organized into individual lines of text,
  called content lines.  Content lines are delimited by a line break,
  which is a CRLF sequence (CR character followed by LF character).

I used `unix2dos` to convert the file.  The generated output passes
icalvalid [1], with the only warnings due to the fact that some events
don't specify DTEND/DURATION.  Adding `days` fields to everyone's YAML
front matter should fix that.

[1]: http://icalvalid.cloudapp.net/
Merge pull request #1 from wking/gh-pages

Dynamic Google Map and iCalendar export from YAML front matter