Fix the logic choosing which verify locations to use

This commit has security implications for simple clients that use `openssl s_client`. To demostrate the issue described in the commit message do:

```
openssl s_client -connect github.com:443 -verify_return_error -quiet -verify 105 -CAfile my_ca.pem
```

Where `my_ca.pem` is any certificate file other than the one that actually signed github's cert. This should fail, but it currently succeeds.

This pull request fixes that. Together with the annoyance that if you _don't_ specify a `CAfile` in the above command it fails, though it should have succeeded. :)

Discovered and debugged together with @errge. 

-------

The intention was obviously to use the user-specified CAfile and CApath _and_ if that fails (eg. user didn't specify anything) to use the defaults. Having `||` instead of `&&` has two implications:

1. If the user doesn't specify anything, we don't use the defaults, so
   verification will always fail. This is mostly a nuisance.
2. If the user _does_ specify something for `CAfile` or `CApath`, we will
   load the defaults _too_. Which have security implications: A simple
   client implementation with `openssl s_client` that wants to check that
   it's talking to the right server by specifying a private CAfile fails
   to achieve the promised security (as the server's certificate will also
   be checked against the default CA list).