fix(core): stop accepting GestureTypes enum as an eventName

[shirakaba]

This PR is related to #10538, 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?

ViewCommon is a subclass of Observable. When overriding addEventListener and removeEventListener, it makes the following changes to the signature:

- addEventListener(eventNames: string, callback: (data: EventData) => void, thisArg?: any, once?: boolean): void;
+ addEventListener(eventNames: string | GestureTypes, callback: (data: EventData) => void, thisArg?: any, once?: boolean): void;

- removeEventListener(eventNames: string, callback?: (data: EventData) => void, thisArg?: any): void;
+ removeEventListener(eventNames: string | GestureTypes, callback: (data: EventData) => void, thisArg?: any);

Although this is allowed in TypeScript, even in strict mode, here are my motivations for removing it:

• there's no real need for it. We can just coerce to string upstream of it. Its one advantage is that it supports expressing multiple events at once, but (aside from there being an appetite to remove support for adding/moving multiple events at once) it seems we're not even using that functionality in practice.
• we're not extensively using the feature anywhere within Core in the first place (only four lines across all of Core).
• it complicates the typings and makes them diverge further from EventTarget.

What is the new behavior?

Accept only strings for event names.

This is not a breaking change within Core (no tests were relying on it, and I've migrated the only four lines relying on it), and any plugins making use of it should see what to do by heeding the updated typings.

[shirakaba]

As the names suggest, these tests are not actually automated tests; they're purely auto-documented code-snippets for use on the old docs site. I thought I'd just remove the now-unsupported ones to save some mental burden when using the search functionality.

[shirakaba]

I've removed the .toLowerCase() as:

1. Event names have mostly been input via the toString() convenience function up until now.
2. Users should have been getting the string keys from the GestureTypes enum to begin with.

To be honest, we can likely remove the .trim() too, but I'd prefer to do that in the PR where we remove support for multiple event names.

[shirakaba]

@farfromrefug As requested, now using the string constants instead (forgot how enums worked).

[CatchABus]

The thing is we have guided people to use the types as explained in old docs for years: https://old.docs.nativescript.org/ui/gestures

How are we going to make up for that?

[shirakaba]

Good catch 🤔

Optimistically, I’d imagine they’d see a compiler error, see that it now accepts only a string, and be able to take a good guess at what the string is (as it comes from the same enum).

Arguably, it’s now left unmentioned in the new docs, so the typings serve as the up-to-date documentation.

I’d rather not handle it at runtime and just pull the plaster, if possible. It’s unlikely to be the only breaking change regarding event-handling that’s to come, so once the dust has settled, we could provide a migration guide based on what makes it into the release. Most likely in the blog post announcing the new release.

[shirakaba]

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

[farfromrefug]

Good with me