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