improve vector scale/rotate interaction

[pixelzoom]

Related to #205, review pointer areas...

In VectorNode, an invisible scenery.Circle is added to vectors, and it's this Circle that is grabbed when the vector is scaled/rotated.

I added code to stroke this Circle in 'red' with ?dev, and it looks like this:

So this seems to be one reason why it's difficult to grab the tip. The Circle is the wrong size (its diameter should be at least as big as the vector's head), and it's not placed properly.

[pixelzoom]

Here's a step in the right direction, where the Circle's diameter matches the head height:

But I'm wondering... Why are we using a Circle? Why not use another invisible arrow, that consists of a head and stubby tail? Or even just a triangle that matches the vector head, that we can then dilate? @arouinfar is there some design reason for using a Circle?

Another wart is that VectorNode creates this Circle regardless of whether the vector can be scaled/rotated. That's extra stuff that's not used for sum vectors, or any of the Equation screen vectors.

[pixelzoom]

I replaced the circle with a triangle that matches the vector's head. And it is created only if the vector can be scaled/rotated.

If you run with ?dev, the triangle will be stroked with 'red', so you can verify that it is aligned with the vector's head. For example:

This triangle has its own separate pointer area dilations, which are currently defined in VectorAdditionConstants like this:

// dilation of vector head pointer areas, for vectors that can be scales/rotated
VECTOR_HEAD_TOUCH_AREA_DILATION: 8,
VECTOR_HEAD_MOUSE_AREA_DILATION: 6,

So with ?showPointerAreas, it looks like this, with a bit more dilation for touchArea:

@arouinfar please review in 1.0.0-dev.26, let me know what you think.

[arouinfar]

@arouinfar is there some design reason for using a Circle?

No, there was never a design specification for circles. The triangular pointerAreas look good to me.