COPYING: Fill in the <YEAR> and <OWNER> markers

This is a separate commit to make is extremely clear what parts of
this file I've written on my own, and which parts I copied from the
Open Source Initiative.  Probably overkill in this case, but sometimes
it's useful if your pulling someone else's work into your repository.

After editing COPYING in my text editor, I committed the changes with:

  $ git commit --all --verbose

We talked about the `--all` option in c481fb5 (README.md: Document the
syntax used in the README, 2013-11-29).  The `--verbose` option option
shows the diff in comments in your editor so you can check them while
you compose the commit message.  This is useful when you're explaining
complicated commits, and it also lets you verify that you are actually
committing what you think you're committing.

COPYING: Add the 2-clause BSD license for this project

The text is from http://opensource.org/licenses/BSD-2-Clause.  I
haven't made any local changes to the text yet, so the `<YEAR>` and
`<OWNER>` markers are still there.  I did wrap the original text to 70
columns to it's easier to read in narrow terminals (which are
traditionally 80 characters wide).

Because I'm not sure I want to use this license yet (maybe I'll use
the MIT license instead?), I've started a new branch for this commit:

  $ git checkout -b bsd-license master

That creates a new branch `bsd-license` based on the current `master`
and checks out the new branch.  You can see which branch you're
usually on using `git branch`:

  $ git branch
  * bsd-license
    master
    mit-license

The asterix marks the active branch.  Once we've checked out the new
branch, creating commits is just like it used to be:

  $ git add COPYING
  $ git commit

Projects usually include licensing information like this explaining
the terms under which others are allowed to make changes.  The file is
often called COPYING or LICENSE.  The Open Source Initiative has a
list of popular licenses [1], as does the Free Software Foundation
[2].

The contents of this commit message are very similar to e8051dc
(COPYING: Add MIT license for this project, 2013-11-29), but I don't
expect both commits to be merged into the master branch.  It's better
to have a commit message that makes sense even for folks that don't
have access to e8051dc in their repository.

[1]: http://opensource.org/licenses/
[2]: http://www.gnu.org/licenses/license-list.html

README.md: Document the syntax used in the README

Explain that the file is written in Markdown, and link to the Markdown
spec and GitHub's markup parsing docs.

After adjusting README.md in my text editor, I compared my working
directory with the index using:

  $ git diff

That looked reasonable, so I committed all the modifications using:

  $ git commit --all

The `--all` option tells Git to automatically stage any modifications
or deletions.  I could have used the following:

  $ git add README.md
  $ git commit

and achieved the same result.  Some people like to stage changes
explicitly, and some like to stage them automatically.  Pick whichever
works best for you.

README.md: Begin versioning by explaining the project goals

I created this commit by writing README.md in my text exitor.  I
staged the file for the next commit with:

  $ git add README.md

I committed the staged version of the file with:

  $ git commit