fix(core): handle GestureObservers the same as event listeners

[shirakaba]

This PR is related to #10537, but can be merged independently. Whichever is merged first will cause minor conflicts with the other, but it's a simple rebase that I'd be happy to take care of.

PR Checklist

• The PR title follows our guidelines: https://github.com/NativeScript/NativeScript/blob/master/tools/notes/CONTRIBUTING.md#commit-messages.
• There is an issue for the bug/feature this PR is for. To avoid wasting your time, it's best to open a suggestion issue first and wait for approval before working on it.
• You have signed the CLA.
• All existing tests are passing: https://github.com/NativeScript/NativeScript/blob/master/tools/notes/DevelopmentWorkflow.md#running-unit-tests-application.
• Tests for the changes are included - https://github.com/NativeScript/NativeScript/blob/master/tools/notes/WritingUnitTests.md.

What is the current behavior?

Although listeners for gesture events are set up in the same way as any other events, there are subtle differences in how they get handled.

• Gesture events accordingly have a few bugs:
  • You can add the same eventName-callback-thisArg gesture observer multiple times.
  • Removing any gesture observer removes all of the same name, regardless of callback-thisArg identity.
• GesturesObserver reaches up into ViewCommon to remove itself from the observer map; that should instead be a responsibility of ViewCommon, as that's the agent that maintains and inserts into the map.
• Unlike with regular events, Gesture events can be called with any thisArg, even falsy values.

What is the new behavior?

• Gestures are now handled just like event listeners.
  • They are identified by their eventName-callback-thisArg tuple.
  • You can't add the same one twice.
  • You can remove multiple at once by omitting the callback and/or thisArg arguments, e.g. via viewCommon.removeEventListener("tap")
• _observe is now protected rather than public. My thought is that we're exposing far too many internal APIs and it prevents us from refactoring our internals in future. This API was not used in any tests, nor was it documented, and is prefixed with _, so it's clearly internal-looking to begin with.

[shirakaba]

@farfromrefug @edusperoni @CatchABus Sorry to poke. Anything holding this back from approval?