Use Xcode9 API For Attributed Versions Of accessibilityLabel, accessibilityHint, accessibilityValue

[fruitcoder]

Basically a reverse of commit b0a5dc1 of my attributedA11y branch (PR #554).
Uncommented the tests, but they can be commented out again (if there was a specific reason).

[ghost]

🚫 CI failed with log

[ghost]

	1 Warning
⚠️	Any source code changes should have an entry in CHANGELOG.md or have #trivial in their title.

Generated by 🚫 Danger

[appleguy]

(I haven't reviewed in detail yet) — are there benefits to landing the new Xcode 9 API now? The prior version check doesn't seem too unclean.

I'm asking just because it's common for developers to have build systems, lagging engineers, etc that are on the older tools for several months after they launch. If we had a functional need to use a newer API, that's a good reason to break Xcode 8; if it's a few characters cleaner in framework code that is rarely changed, maybe not worth doing so soon.

That said, I think it is super awesome that you contributed the attributed a11y methods and really appreciate you working on improving the code!

[fruitcoder]

Hey @appleguy! I actually did this, because I though I was supposed to (issue: #636)

[Adlai-Holler]

Huy @appleguy @fruitcoder take a look at the linked diff if you wouldn't mind. It should give us backwards compatibility without too much ugliness.

[nguyenhuy]

@fruitcoder I'm closing this PR in favor of #650. Thanks for taking the first stab and facilitates discussions around backward support for Xcode.

@appleguy We discussed internally and agreed to support one version back. Thoughts?

[appleguy]

@nguyenhuy @Adlai-Holler sounds like a great policy to support -1 version. If there is a compelling reason to drop support, it should be an option though. It seems like mainly, for the smallest convenience features, those ones might not be worth dropping support.

Good news too, since I found out my automated performance testing system is still running Xcode 8.3 (and I can't update it myself).