entry: Die unless we're parsing a version 2.0 iCalendar

RFC 5545, section 3.7.4 (Version) describes this text field.  Until I
actually see something using using the (minver ";" maxver) syntax,
I'll just require everything to be version 2.0.

entry: Adjust entry parsing to handle nested entries (BEGIN & END)

Now Entry can parse a whole VCALENDAR, and return a nested tree of
Entry instances.

This also makes Feed a subclass of Entry.  The new entry BEGIN/END
parsing is derived from the old Feed BEGIN/END parsing.

entry: Hash entries by their UID (when possible)

From RFC 5545, section 3.8.4.7 (Unique Identifier):

  Conformance:  The property MUST be specified in the "VEVENT",
      "VTODO", "VJOURNAL", or "VFREEBUSY" calendar components.

README: Add installation and testing advice

README: Flesh out the description with links to other aggregators

Unfortunately, none of the existing aggregators are libraries.

MANIFEST.in: Add a basic manifest

We don't have any READMEs under test/ yet, but I imagine we will
eventually.

setup.py: Add a boilerplate setup.py

.gitignore: Add the usual suspects

.update-copyright.conf: Add copyright configuration

Use my external update-copyright package to maintain copyright blurbs.

http://pypi.python.org/pypi/update-copyright/

entry: Make Entry a subclass of dict

This gives us the familiar interface, and moves key/value processing
to a one-time-per-entry loop in ._fill_dict().

entry: Add Entry.process() and .get*()

Because we will definitely want a Pythonic API to access entry items.

feed: Use splitlines() instead of split('\r\n') in Feed.process()

The specs require '\r\n', but we don't have to be that strict.

aggregator: Escape VERSION and PRODID

From RFC 5545, sections 3.7.3 (Product Identifier) and 3.7.4
(Version), these are both text fields.

text: Add escape() and unescape() for RFC 5545 compliance

aggregator: Add processors field for post-fetch processing hooks

feed: Turn Feed into a set of entries

entry: Add an initial Entry implementation

feed: Only fetch if we haven't already (or if we're forcing a fetch)

aggregator: Add an initial Aggregator implementation

Currently broken pending support for `for entry in feed`.  The version
and product identifier fields are required, as specified in RFC 5545,
sections 3.7.3 (Product Identifier) and 3.7.4 (Version).  They'll also
need to have special characters (e.g. commas) escaped, but I'll get to
that later.

feed: Implement feed.fetch()

Add __version__, __url__, and USER_AGENT to the package namespace, so
we have a useful user agent to use when fetching.  The fetch code can
hard-code UTF-8 as the feed charset, because RFC 5545, section 6
(Internationalization Considerations) reads:

  Applications MUST generate iCalendar streams in the UTF-8 charset
  and MUST accept an iCalendar stream in the UTF-8 or US-ASCII
  charset.

From a character conversion standpoint, that means we can always use
UTF-8, because US-ASCII is a subset of UTF-8.

test/data/geohash.ics: Pull out geohashing example from Feed doctest

This makes it easier to reuse the test data in other locations.

Also escape commas in the data.  From RFC 5545, section 3.3.11. Text:

  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.

feed: Stub out the Feed class

Begin versioning under the GPLv3