Fix bug where latest point_scale is not used

If you changed the point_scale, it had no effect until you sent a new set of
points. This is how I wrote it, but I wasn't intending this behaviour. If you
change point_scale before starting the program (but after sending the points),
or even in the middle of the execution of the program, it should use it. Now,
instead of scaling the points in the transform method, the distance is simply
multiplied by point_scale in the set_drive_time function.
More work on server/client timeout

The gevent queue timeout is good, but I forgot that it raises an exception when
it times out. When I catch the exception, I have to return something, so I
decided to return None and then took this into consideration in the server's
handle_post method. Now, if a command returns None (instead of a status string),
the server will send a zero-length message with status 204 NO CONTENT. I'm not
sure if this is the best header to use, but it doesn't really matter.

In post function of controls.js, I added another callback for failing (separate
from client timeout). This is called if there is a response, but its header is
not 200 OK. The updateStatus function simply calls itself again if this happens,
just like what it does when it times out. The other posting functions add a
message to the console indicating the failure and its status code.

I decided to leave the client timeout at 30 seconds and change the server
timeout to 31 seconds. Now, the client will give up just before the server does.
The server will respond with 204, but the client won't get that because it is no
longer listening for it. I could do it the other way around and have the server
give up one second before the client; in this case, the client would never time
out (in these specific circumstances) because the server would always response
with 204 in time (or 200 some time earlier). I don't think either option has an
advantage over the other, so I'm leaving it at client-30 and server-31 for now.
Fix more issues with long-polling & timeouts

I keep thinking I am done with this, but then a new issue appears! When I
started the Tracie program, sometimes it would not should the first one or two
statuses for some reason. I figured something was wrong with the queue access --
somehow those statuses were getting lost. I realized that there IS an advantage
to making the server time out first, instead of the other way around (which is
what I did in the last commit), because if the client gives up, the server can
still try to return something from the queue, and then that item is lost
forever.

So I changed it to server-25 and client-30, but that didn't solve my problems. I
changed the client timeout to be very small for testing purposes, and at some
point my browser started crashing. The I noticed that the errors in the Web
console were growing exponentially! This is because each failed or timed out
status update starts a new one -- but for some reason, a timeout causes
ontimeout to be called AND the request to be completed with status 0 (not 204),
so each timeout triggered two new status updates.

I added a check for a zero status. I have no idea why those happen, but now they
will be ignored. The server times out before the client and responds with 204 NO
CONTENT, and the client sees this and initiates a new request without timing
out. One good thing about this is that there aren't any errors in the JS console
-- I probably shouldn't have been using timeouts for things that were supposed
to happen before. I think everything is finally good now.

The bug I mentioned earlier, about statuses being missing, was very hard to
reproduce, even before these changes. I think its gone, but I can't be sure.

I also made the Controller's start method use start_later on its Greenlet
instead of an immediate start, because the first status of the program was
beating the "program resumed" message to the console. That seems to have fixed
it. It would probably be better if I had ALL messages in a queue, guaranteed to
appear in the console in the order that they occurred, but that would be a lot
of work for little gain at this point.
Use 'points:' prefix; resend points on switch

Before I was assuming that any client command beginning with '[' was JSON data
for the points. Now, a prefix of 'points:' is used for consistency with
everythign else. Also, when you switch to the Tracie program, the points are
resent to the server (before you had to go to the drawing page and back, which
was not intuitive).