_layouts/mapcal.html: Add FullCalendar-based calendar

FullCalendar is dual licensed MIT/GPLv2.  SWC uses the MIT license for
code, so including the FullCalendar code is allowed.  FullCalendar
itself uses JQuery, which is also MIT licensed.

Start dates are extracted from the `_posts/YYYY-MM-DD-...` filenames.
Day spans (for multi-day boot camps) come from a new `days` value in
the YAML front matter.  It should be possible to parse this out of the
less structured `dates` value, but that seemed like more work than it
was worth.

Incidental changes:
* Remove JQuery-latest import from footer-javascript.html, because it
  conflicted with the now-local jquery-1.8.1.
* Make the map a bit wider, because there's only so far you can
  scrunch FullCalendar before things start going wonky, and it's nice
  to have both the map and the calendar be the same width.

I used FullCalendar v1.5.4, which is the current release.
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.

There is a good deal of overlap with the existing YAML front matter
`dates` and `days`.  In principle, `days` and `dates` could be
calculated from `time` and `end`, but Liquid doesn't expose enough
date-parsing logic for this to be feasible (as far as I can tell).

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 again 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 JavaScript FullCalendar and 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.