workshops/test/__init__.py: Use an explicitly relative import

With the absolute_import future for Python 2 compatibility [1].  This
avoids errors like the following on Python 3:

  $ make test
  ...
  ======================================================================
  ERROR: workshops.test.test_event (unittest.loader.ModuleImportFailure)
  ----------------------------------------------------------------------
  Traceback (most recent call last):
    File "/usr/lib64/python3.4/unittest/case.py", line 58, in testPartExecutor
      yield
    File "/usr/lib64/python3.4/unittest/case.py", line 577, in run
      testMethod()
    File "/usr/lib64/python3.4/unittest/loader.py", line 32, in testFailure
      raise exception
  ImportError: Failed to import test module: workshops.test.test_event
  Traceback (most recent call last):
    File "/usr/lib64/python3.4/unittest/loader.py", line 312, in _find_tests
      module = self._get_module_from_name(name)
    File "/usr/lib64/python3.4/unittest/loader.py", line 290, in _get_module_from_name
      __import__(name)
    File "/.../amy/workshops/test/__init__.py", line 1, in <module>
      from test_event import *
  ImportError: No module named 'test_event'
  ...

[1]: https://docs.python.org/2/library/__future__.html
workshops/test/test_event.py: Use assertCountEqual for Python 3

Python 2.7 has assertItemsEqual, but it's called assertCountEqual in
Python 3.2+ [1,2].

While adding the sys import, I also pulled the datetime import up into
the standard-library import block [3].

[1]: http://bugs.python.org/issue17866
[2]: https://docs.python.org/2/library/unittest.html#unittest.TestCase.assertItemsEqual
[3]: https://www.python.org/dev/peps/pep-0008/#imports
Fixed Issue #102, adds PyYAML to requirements.txt
Merge remote-tracking branch 'cudevmaxwell/102-fix-requirements'

This should have happened with 3290893c (Generating YAML used by main
Software Carpentry website, 2014-12-18).

* cudevmaxwell/102-fix-requirements:
  Fixed Issue #102, adds PyYAML to requirements.txt
Merge pull request #67 from wking/test-relative-import

Get the test suite passing in Python 3
workshops/models.py: List choices for Person.gender

This is not a free-form field, since we're only allowing 'M' (for
male), 'F' (for female), 'O' (for other), and NULL [1] (we don't know)
in the database.  Telling Django about these choices [2] gets us the
convenient get_FOO_display field and better form UI (drop down
selections) and validation.  The field also sets 'blank=True' [3] to
allow folks to edit their profile without specifying any of the gender
choices.

[1]: https://docs.djangoproject.com/en/1.7/ref/models/fields/#null
[2]: https://docs.djangoproject.com/en/1.7/ref/models/fields/#field-choices
[3]: https://docs.djangoproject.com/en/1.7/ref/models/fields/#blank
workshops/migrations/0027_auto_20141222_0144.py: Explicit person.gender choices

This is the template created with:

  $ python3.4 ./manage.py makemigrations
db.sql: Migrate to person.gender choices

With:

  $ make database
  $ python3.4 ./manage.py migrate
  $ sqlite3 db.sqlite3 .dump > db.sql
Merging @wking's updates to gender selection and re-doing changes to migrater.

Instead of `------`, the pulldown for choosing gender should display `unknown`.