Refactored search app and rewrote search tests

Cleaned up the API for SearchForm and SearchApiClass.  Fixed a bunch
of weirdness there:

  - The API of SearchForm was optionally inputting a haystack
    SearchQuerySet, but we always wanted to use that
  - For most searches we would run apply_query() twice, which resulted
    in weird search queries
  - In general there was just a bunch of redundant code

Changed the tests so that they don't use fixtures and they don't hit
the solr database.  Using solr in the tests is slow and it's easy to
mess things up if you don't clean up the state after the test.

Instead we simply test if we are creating the correct queries and
assume that haystack will do its job correctly.  Also moved basically
all the logic into the SearchForm and tested that instead of testing
the entire rpc function which does a bunch of other stuff.

Tests now run in under a second on my machine instead of about 45
seconds before.
Removed old youtube syncing code

Removed the accountlinker app along with the old code that handled
adding youtube description credits and syncing youtube videos.  All
this is handled by the externalsites app.

Removed the third_party_accounts many-to-many field from the
CustomUser and Team models.

Rewrote a bunch of tests to use factories instead of fixtures.  One
big problem with fixtures is if you change your DB schema they tend to
stop working.  Couple of notes on the changes:
  - Removed the widget tests.  These were not easy to rewrite and we're
    trying to phase out the widget app anyways.
  - Removed the credit tests from videos.tests.video_types.
    externalsites.tests.credit should test the same stuff with the new
    code.
  - Removed the TestCeleryTasks.test_notification_sending test.  That
    code seemed really hard to follow and I believe that we test the
    same functionality with other tests.
  - Mocked out http.url_exists() during the tests and always return
    True
  - I removed a bunch of tests for view code.  These tests were either
    testing really trivial things, like if we get a 200 status code.
    Or we had tests against the model code and we were just duplicated
    them with the view code.  If we structure things nicely so that
    all the heavy work is done in the model code, or somewhere else
    outside the view function, then I don't think it helps much to
    test the view.