View drawing APIs should restrict drawing to `Viewport`

[tig]

This is mostly fixed in #3323.

What won't be addressed there is:

• ConsoleDriver.Move should not be public and should only be called by View.Move.
• It should not be possible for a View to change Driver.Clip.
• Driver.ClearContents sets Clip to Screen. This is dangerous. Either move the Clip = elsewhere or restrict who can call ClearContents
• Driver.AddStr has bugs in it related to Clip; there are codepaths where Contents's bounds are exceeded even when IsValidLocation is true.
• Views and Scenarios that use Driver. anywhere should be updated to use the equivalent View API. IOW, we should remove as much coupling between View and Driver as possible

Already adressed:

• View.Clear - I've already done this for Clear in BoundsToScreen is confusing #3298
• View.Move - Before the call to Driver.Move, ensure coords are w/in Bounds
• View.SetNeedsDisplay

Additionally: We should make Driver.AddRune/AddStr/Move internal and change all built-in views that use these APIs use View.AddRune/AddStr/Move instead

These are all causes of confusion and potential bugs.

I'm not a fan of letting views draw in arbitrary places. If there's use case for a view drawing outside of it's bounds (once Adornments is finished), please let me know!

[dodexahedron]

Agreed that a View should only be able to draw inside its defining Rectangle, regardless of the properties of things it contains.

Most of that math can likely be calls to Rectangle.Intersect method, since that's exactly the result desired, in terms of the resulting rectangles. Caching those values until invalidated may be a good optimization there.

An important question, though:
How are out-of-bounds subviews handled?

• Do we throw an exception at draw time?
  • I don't think that's a good idea.
• Do we throw an exception on an attempt to set a property to a currently-illegal value?
  • Also not my first choice, but better than the above.
• Do we still draw that subview, but just truncate whatever portion of it is out of bounds?
  • I think this is the best behavior, though potentially one of the more difficult options to implement.
• Do we still draw that subview, but treat the partial remaining area as its new bounds for its own layout operations?
  • That sounds like a nightmare for the consumer, to me.
• Do we just not draw the offending subview at all and log the failure?
  • Easy but kinda odd. Logging helps though.... IF the consumer is logging at all.
• Some combination of the above, with specific behavior for each view configurable by the consumer?
  • eek
• Some other behavior?

[tig]

An important question, though: How are out-of-bounds subviews handled?

• Do we throw an exception at draw time?

Nope. I think it's perfectly acceptable for a view to be placed "offscreen".

• Do we throw an exception on an attempt to set a property to a currently-illegal value?

Depends. Specifically: X/Y/Height/Width/Frame/Bounds: No.

• Do we still draw that subview, but just truncate whatever portion of it is out of bounds?

No. If View.Move and ViewAddStr clamped as suggested, the driver will never see the output. Also, If clipping worked correctly, this wouldn't be a question (or the right question). See #2606 as well as all the TODOs I've littered the codebase with.

• Do we still draw that subview, but treat the partial remaining area as its new bounds for its own layout operations?

No.

• Do we just not draw the offending subview at all and log the failure?

No.