Fix bug where pipelines can get stuck

Summary:
The code for getting the barriers to trigger when filling a slot was using a
regular datastore query, which meant that in some situations, a recently-created
barrier wouldn't get loaded because the query is only eventually consistent.
This meant that a pipeline would sometimes never start, so the pipeline job as a
whole would hang.

The conceptual fix is for slots to have a list of barriers listening to them, so
that they can do a strongly consistent read of that list. Each time a barrier is
created or modified, it needs to add itself to all slots that the barrier is
listening to. Since it's difficult to safely append to a bunch of ListProperties
across multiple entity groups, these "lists" are actually represented as
BarrierListener entities that are child entities of their SlotRecord. This means
that getting the barriers listening to a slot can be done with a strongly
consistent ancestor query on the slot, and appending to multiple slots (across
multiple entity groups) can be done with a batched put (which doesn't need to be
transactional, since BarrierListeners only need to represent a superset of
barriers listenting ot a slot).

Test Plan:
-I ran /admin/bigbingo/summarizer_end_to_end_test 5 times and it consistently
passed. Previously, it would get stuck about half of the time.
-I changed the code to occasionally (with 20% probability) raise a runtime error
before the transaction in transition_run and ran a stress test that launched 50
pipelines, each with 10 InOrder pipelines, and it succeeded.

Reviewers: chris, mattfaus

Reviewed By: mattfaus

Subscribers: jace

Differential Revision: http://phabricator.khanacademy.org/D7549