Remove final in protocol extensions

[KingOfBrian]

This PR generates an error when the final attribute is added to a function or variable inside of a protocol extension. This matches the current semantic model -- final only disables overrides for class types, and it has no effect on protocol extensions. This makes final syntax consistent across struct, enum and protocol types.

This PR also cleans up the reporting of the message by adding a fixit, and only reporting the error once in variable declarations with child declarations. For instance, the error message is currently reported multiple times if a final variable declaration has implicit getters and setters.

This error message also uncovered a lot of usage in the test suite, and a few places where final was used in extensions of a Error protocols in Foundation.

Resolves SR-1762.

[slavapestov]

Can you make it a warning in Swift 3 mode and add a testcase to test/Compatibility/?

[KingOfBrian]

It is a warning in Swift 3 and I added test/Compatibility/final_protocol_extension.swift which checks the warning in Swift 3 mode. Did I miss a case there?

[slavapestov]

Oh sorry I missed that you already did that. Looks good, thanks!

[slavapestov]

@jrose-apple Does this look ok to you?

[slavapestov]

@swift-ci Please smoke test

[jrose-apple]

I mentioned on the bug (and Joe concurred) that this should still go through swift-evolution, since it's an additional break between Swift 3 and Swift 4. It's tiny but that doesn't automatically mean we should just do it.

[jrose-apple]

This is not a change we should make just yet. We're using our existing test suite as source compatibility tests.

[KingOfBrian]

Are you referring to the -swift-version 4 or to the changes to the tests themselves? I thought that all of the source compatibility tests (for v3) were being put int test/Compatibility. I added -swift-version 4 here in an attempt to follow the pattern I saw in test/attr_[escaping|inlineable|objc], but glad to change anything as needed.

[jrose-apple]

-swift-version 4. You only get to add that if everything in the file is also being tested in Compatibility. (Right, @slavapestov?)

[jrose-apple]

We can certainly put the "cleanup" changes in to remove final where it's not necessary, and we can add the warning unconditionally for now.

[KingOfBrian]

The attr->invalidate() that I added to remove duplicate warnings was causing the ASTVerifier to fail when comparing the func decl final state to the storage decl final state. Instead of invalidating the attribute, I am removing it which should make sure that the func and storage final states are consistent, and that the error message only occurs once.

I also made a PR to foundation(apple/swift-corelibs-foundation#917) to remove the two places where this warning would occur.

[alblue]

@swift-ci please smoke test

[jrose-apple]

Thanks, Brian!