Fixed up concerns about backwards compatibility

[pjebs]

@cenkalti

• Changed PermanentError to FatalError (name is self-explanatory)
• Added support for Go1.7+'s context package whilst providing support for context for older versions of Go.

[coveralls]

Coverage decreased (-4.6%) to 77.723% when pulling 422bf8a on skylovely:master into 5d150e7 on cenkalti:master.

[cenkalti]

@pjebs

• You are introducing a new error type FatalError that is copy/paste of PermanentError. This creates confusion and does not help in any way. The change is unnecessary.

• You also break builds by changing import path of context package for Go users using version >=1.7. Read the thread here for details: Go 1.7 uses import "context" grpc/grpc-go#711

Please open an issue to discuss before sending more pull requests.

[pjebs]

@cenkalti
I have a build tag at the top for the different context type. +// +build go1.7
In terms of breaking builds, it won't break builds for go less than 1.7.
For builds of go1.7+, it will potentially break builds, but that is because it was a mistake in the first place to NOT have the build tags. Those go1.7+ uses will probably WANT to use the context package directly from the standard library.
What is your transition plan as Go goes from 1.7 -> 1.8 -> 1.9. Are you going to ignore the standard library context package until the year 2039?

[pjebs]

Regarding the addition of FatalError. It is done because the name itself is self-explanatory. So while the change is technically unnecessary, it is backwards compatible AND it improves your package overall.

[cenkalti]

• It is not a mistake to not using build tags. Source code (thus import path of context package) should not depend on the version of the compiler used. Every package that imports context package has the same problem. You have duplicated the contents of the context.go in a different file, it is ugly. If type aliases come with 1.9, then the transition will be seamless: Revert "Update to standard library context package." golang/protobuf#326 (comment)

• Maybe the name PermanentError is not perfect but it seems okay to me. It is decided once and I don't want to change it. If it is not self-explanatory we can explain better in docs.