Motivation:
We cannot assume that `CertificateFactory` implementations are
thread-safe, since they contain complicated parsing logic which may be
implemented as stateful operations depending on the particular provider
used at runtime.

Modification:
Remove the singleton instance and just create a new `CertificateFactory`
every time.
Creating these factories should not be the most expensive thing,
regardless of provider used.

Made the `wrapped` field volatile to ensure visibility across threads,
effectively obtaining safe publication for the `X509Certificate` object.
This is important because `X509Certificate`, just like the
`CertificateFactory`, may have any number of implementations at runtime
and there are no guarantees about their thread-safety or immutability.

Made the test dig into the SANs and compare the data directly, instead
of relying on the `Collection.equals` implementation, which could be
anything, just like with the other objects above.

Result:
`LazyX509Certificate` is now thread-safe.

Should fix weird flaky test failures, such as:

```
[ERROR] Failures:
[ERROR]   LazyX509CertificateTest.testLazyX509Certificate:83 expected: java.util.Collections$UnmodifiableCollection@757bd65c<[[2, www.foo.com]]> but was: java.util.Collections$UnmodifiableCollection@2c32b649<[[2, www.foo.com]]>
```

(cherry picked from commit 8e147e5)