WIP: weight movement functions to share velocity

Currently the flocking "repel" behaviour and the "arena" (or river,
moat, etc.) behaviour conflict and the velocity limit applies to each
equally; since the "arena" behaviour always move the same distance and
the "repel" behaviour varies, the "arean" behaviour dominates: this is
why we see the boids line up along the current instead of across it.

My plan is to weight the movement functions so that flocking has more
pull than the arena. If the "repel" behaviour only pushes 1 distance,
where arena pushes 5, but "repel" is weighted at .8, then the effects
should be more even. The boids will still probably line up, but this can
be tweaked.

If the combined movement functions exceed the velocity, then the allowed
movement should be shared by the movement functions according to their
weights:

i.e. if A moves 10 and has a weight of .8, and B moves 5 and has a
weight of .2, but the velocity is 9, then we can only move 60% of the
distance; A gets .8 of the velocity and B gets .2; i.e. A gets 7.2 and B
gets 1.8.

I don't like the feel of this because A moved 100% more than B, but gets
400% more movement in the end; it kind of feels like A should get 800%
more movement since it had four times the weight plus twice the
movement.

Another option is to pass the velocity to each movement function and
have it adjust it's movement according to it's share of the velocity.
Ditch weights, use scale instead

I was struggling, unnecessarily, to use weight ratios to do complex
calculations to get different movement functions to have more or less
influence. It seems like I can get the same thing just by scaling the
results of the different movement functions and then capping the
aggregated results.
Fix world tests

Tested that world.movements is created and copied properly; I was only
testing that world fields were set when changing boids, not that other
fields were preserved.
Fix velocity as string bug

I was reading velocity in as a string and then appending it to
coordinates with + instead of adding it to coordinates with +
Remove velocity bounding

I was previously bounding the flocking repel behaviour by the velocity;
it's actually easier to allow the flocking to scale beyond the velocity
to properly offset other behaviours and then scale later.

e.g. if the movement function 1 wants to go to {x+2,y+2} and flocking
wants to go to {x-10,y-10}, then we'll get a final point of {x-8,y-8}
which will be in completely the opposite direction of the first movement
function, but less so, and then we'll scale that back to the velocity.

In this way we don't have to account for what proportion of the allowed
velocity each movement function should account for, combined with the
weight of the movement function. It gets really messy that way.
Add log functions and calls, comment them all out

Added some logging functions to try and figure out where I was getting
really weird coordinates from; turns out it was a sting velocity read
from the velocity textbox.

I don't technically need to comment out all the logging, since the
logging checkbox is off by default, but ... I like to.
Update tests

1) We don't bound the flocking repel behaviour by velocity since we
scale the the result and then bound the aggregated movement function
results later - removed the velocity bounding test

2) Test that aggregating zero adjustments retuns the original boid
location
Round constrained point, fix test

When constraining points to fit the velocity I'm rounding the values so
we don't get crazy decimals in the coordinates.
Merge branch 'topic/weighted-movements'