feat(v-on): add more precise names for pointer modifiers

[st-sloth]

re #6877

What kind of change does this PR introduce? (check at least one)

• Bugfix
• Feature
• Code style update
• Refactor
• Build-related changes
• Other, please describe:

Does this PR introduce a breaking change? (check one)

• Yes
• No

If yes, please describe the impact and migration path for existing applications:

The PR fulfills these requirements:

• It's submitted to the dev branch for v2.x (or to a previous version branch), not the master branch
• When resolving a specific issue, it's referenced in the PR's title (e.g. fix #xxx[,#xxx], where "xxx" is the issue number)
• All tests are passing: https://github.com/vuejs/vue/blob/dev/.github/CONTRIBUTING.md#development-setup
• New/updated tests are included

If adding a new feature, the PR's description includes:

• A convincing reason for adding this feature (to avoid wasting your time, it's best to open a suggestion issue first and wait for approval before working on it)

Other information:

Having a warning "uncaught" with toHaveBeenWarned fails otherwise valid tests. Adding assertions about warnings seems excessive in those tests. What is the proper way to do it?

Also questions posed in #6877 (comment) are relevant. Currently names are primary, secondary, auxiliary for left, right, middle correspondingly.

[yyx990803]

Thanks for the PR!

I think it makes sense to assert that the warning has indeed been warned whenever it should be. That's the point of the warn check.

Naming looks good.

Final note: we probably won't merge/ship this until 2.6 since we want to avoid introducing deprecations in patch releases.

[st-sloth]

Thank you!

I'll add the warn checks in a bit.

2.6 is totally fine. But if the new API is welcome in a patch release while deprecation warnings are not, and if it would be beneficial, I can move deprecation warnings into another PR that would wait for the minor version bump and keep new names with working old ones here for the patch.