Refactor `MouseEvent` and `MouseEventEventArgs` to simplify

[tig]

Similar in spirit, but somewhat less scope, than #2927

• New/OnMouseEvent now uses just MouseEvent.
• New/OnMouseClicked now uses just MouseEvent.
• Better document/rename OfX/OfY
• Move mouse stuff out of Responder and into View so Responder can be nuked
• Add a docs/mouse.md
• Beef-up/refactor mouse unit tests
• Build MouseBindings per #Command is too tightly coupled with KeyBindings #3778
• Merge MouseEvent and MouseEventEventArgs into a single class.
• Engineer something that removes the need for Responder.IsOverridden which breaks all rules of OO design.
• Ensure all library code uses consistent naming/usage
• Ensure all Scenario code uses best practices related to new design.
• Ensure all API documentation is awesome

[tig]

Partially fixed in #3372.

[dodexahedron]

BTW:

For adherence to the dotnet design guidelines for events, all EventArgs classes should end in "EventArgs" and should not be mixed use classes outside of events themselves (Key, for example, is used both ways - I have a stashed change somewhere that's probably way obsolete by now that fixed that).

Inheriting from EventArgs also used to be recommended, but is now just a soft suggestion.

Here's one of the best of the various documents about guidelines for events:

https://learn.microsoft.com/en-us/dotnet/csharp/programming-guide/events/how-to-publish-events-that-conform-to-net-framework-guidelines