Fix Bugs with Bounding Box Initialized at Runtime

[marlenaklein-msft]

Fixes the errors reported in #543, as well as current behavior where an empty game object initialized at runtime will have unreasonable bounds values for one frame and a non-empty prefab like the coffee cup will have handles incorrectly enabled for one frame:

This change ensures that the LateUpdate in BoundsHandleInteractable prevents incorrect vector values and division by zero, and the other odd behavior for that first frame.

[marlenaklein-msft]

Issue 1: Handles Incorrectly Appear
The handlesEnabled variable is applied during SqueezeableBoxVisuals' Update. If an object with handles disabled is initialized at runtime, BoundsHandleInteractable's LateUpdate is called first and the handles will incorrectly appear for that first frame.
Solution: Call Update from Awake in Squeezable Box Visuals, make a protected flag, or delay LateUpdate until after Update in BoundsHandleInteractable.

Issue 2: Errors logged for invalid scale
In BoundsHandleInteractable LateUpdate, the local scale is set to 1/transform.lossyscale. When transform.lossyscale is 0 we get an error from division by 0. The lossyscale being 0 is attributable to the grandparent object (SqueezableBoxVisuals) which has its bounds set by BoundsControl's ComputeBounds which is called from BoundsControl's Update.
Solution: Check explicitly for division by 0, change the call ComputeBounds (complicated to refactor), or delay LateUpdate until after Update in BoundsHandleInteractable.

Issue 3: Star-shaped explosion when colliders are enabled with invalid scale.
Solution: Move enabling of colliders to Update or delay LateUpdate until after Update in BoundsHandleInteractable.

[AMollis]

One comment :)