bootstrap-sass (w00t)

* Update interim-bootstrap to use the partials from bootstrap-sass,
since some of the names have been changed (and we're using the
Bootstrap 2 javascript now). This should make it easy to keep the
file up to date with the version of Bootstrap we're using.
* Use interim-bootstrap instead of bootstrap-complete in default.css to
avoid the little problem I ran into with Bootstrap + Blueprint grids
not getting along. :)
* Revert the CSS class change (from .span-24.last to .row) in
layouts/application since interim-bootstrap works around that problem.
* Get rid of .icon-black since it's not needed.
* Remove the 60px padding on the page body since it isn't needed and
causes problems with the single post view.

This reverts commit a0a804e8.

Upgrade our current Bootstrap 1 and 2 dependencies to use Bootstrap 2.0.2
from the bootstrap-sass gem.

I had to modify layouts/application to get the stream page to render properly,
looks like a slight conflict between Bootstrap and Blueprint grid systems, with
.span-24 instead of .row I was seeing the whole right bar dropped to the bottom
of the page below the left bar.

I also modified two other templates since Bootstrap 2.0.2 includes a "badge"
class that was making our navbar badges look funny. :)

move jasmine to development and test env, update it

YAML gotchas part 2: you can't use those references or whatever they're called before they are defined

This reverts commit ecf77b6a.

composer touchup; added controls to the bottom; centered input area; removed forms.Base view

Fix tests

double wait time to see if travis responds to that, as its not even getting to the ording issue at this point

Revert "ensure that time is always far beyond last post creation"

This reverts commit 749b403d.

Revert "make Timecop travel persistent for the whole run"

This reverts commit 5d9bdd80.

Revert "Timecop post creation for cucumber"

This reverts commit dba3dbbf.

oh yeah Timecop is really the best solution... hmpf

So now we're getting dirty, this wouldn't be necessary with my solution...

after much sleuthing, this is an extremely hacky way to limit the
amount of public post _ids we are pulling back with every query.
previously, for unknown reason, we were pulling back all of them from
people you are connected to, and doing giant in queries which were
causing bad things to happen.  As far as I can tell, we are in fact
keeping track of the page( i.e. max time and offset) so there was no
need to pull all of them back.  This whole file is a huge clusterf*ck,
so it really should just get totally refactored, as the stuff that is
happening is not really as scary as it looks :(