Expand convex hull bounds by half a pixel per side

[adroitwhiz]

Resolves

Resolves #528

Proposed Changes

This PR expands convex hull bounds by the radius of half a pixel on each side of the bounding box.

Reason for Changes

Say you have a costume like this:

The pixels of said costume can be treated as square color samples taken at the pixels' centers:

The convex hull algorithm calculates the hull based on the pixels' centers, not taking area into account:

As such, bounds calculated from the convex hull need to be enlarged by the "radius" of each pixel.
If pixels were circular, this would be half the "diameter" (aka the drawable's Scratch-space scale), but since they're square, it's actually (√2 / 2) * the diameter.

This will probably change:

• The position of text bubbles (probably not a big deal)
• "If on edge, bounce" behavior (probably a bigger deal)
• Fencing behavior (shouldn't be using the convex hull anyway)

If the "if on edge, bounce" behavioral change is a compatibility issue, I can redo this once there's architecture in place for separating a sprite's "logical" bounds and texture bounds, so the old tight bounds can be used for bouncing and the new expanded ones can be used for stamping.

EDIT: The current "if on edge, bounce" behavior is extremely inconsistent both with itself and 2.0 (you can get this sprite to begin phasing through the walls if you move it into a corner) so this hopefully shouldn't affect compatibility any more than the current behavior already has.

A semi-related issue you may run into when investigating this further is that getConvexHullPointsForDrawable does touching tests at the sprite's "logical size", so double-resolution bitmap costumes (in 3.0, that means all of them) are sampled at half their actual resolution.

This means that, incidentally, double-resolution bitmap sprites with odd-numbered resolution dimensions (like the black circle I linked above in 349149479) appear to be properly fenced currently, but will be fenced half a texel too far inwards by this change. This is because their "logical" sizes are their resolutions divided by 2, and we've started rounding that size up. However, bitmap sprites with even-numbered resolution dimensions were fenced too far outwards, and this change fixes that.

[cwillisf]

Suggested change

	const halfPixel = 0.7071067811865476 * scale;
	const halfPixel = Math.SQRT1_2 * scale;

[adroitwhiz]

Waiting for all the other convex hull issues (#479 and #592) to be resolved before redoing this

[adroitwhiz]

Closing in favor of #724