re-arrange bingo alternative mapping code for better performance

Summary:
most of this is just related to re-ordering the queries
in user_experiment_info.q so that the (biggest) join (with
UserData) comes last.  This is good practice for performance reasons.
I was a bit disappointed with the relative lack of speedup, though.

Perhaps most significantly, there was a small but devastating bug
in bingo_alternative_selector.py where the weights were being
cast as float instead of long.  This had the effect of completely
scrambling the assignment of users to alternatives.

Test Plan:
manually ran the user_experiement_info.q contents on an
interactive Hive cluster.  vars were set as:

set hivevar:dt=2013-02-14;
set hivevar:EXPERIMENT='growth mindset header';
set hivevar:EXP_PARTITION='growth-mindset-header';

Reviewers: jascha

Reviewed By: jascha

CC: chris, james

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