PreconditionFailedError does not have the reason for the failure.

Steps to reproduce it.
1. Try to add a member that was already part of the etcd cluster.
2. You will get a PreconditionFailedError. (With no message property)
3. But when I used the etcdctl to add a member that was already exist that clearly says the member already exists and the status code also signifies PreconditionFailedError.

The Expectation is when there is an Error thrown, we need to identify the reason for the failure because there can be more than one reason we may be throwing the PreconditionFailedError, to differentiate between each other, we need a message in Error, that should describe about the reason.
The Exception stack-trace is below.
```
Traceback (most recent call last):
File "/usr/local/rackman/lib/python2.7/site-packages/flask/app.py", line 1949, in full_dispatch_request
rv = self.dispatch_request()
File "/usr/local/rackman/lib/python2.7/site-packages/flask/app.py", line 1935, in dispatch_request
return self.view_functions[rule.endpoint](**req.view_args)
File "/usr/local/rackman/app/kube_master_mgr.py", line 483, in add_etcd_member
response = self.etcd.add_member(peer_urls)
File "/usr/local/rackman/lib/python2.7/site-packages/etcd3/client.py", line 48, in handler
_translate_exception(exc)
File "/usr/local/rackman/lib/python2.7/site-packages/etcd3/client.py", line 32, in _translate_exception
raise exception
PreconditionFailedError
```

Start in etcd3/client.py at _translate_exception and the handler referenced in the traceback, then reproduce the duplicate-member request through add_etcd_member. Compare the client exception with the reason reported by etcdctl. Done means PreconditionFailedError exposes a message that identifies the failure reason rather than producing an empty message.

Written by the indexing model from the issue text.