The Active Directory support was largely built around ldap:// URIs,

rather than supporting ldaps://. This did attempt to invoke TLS

support, which would switch over to a secure connection if available,

but that either wasn't working or didn't work in all configurations.
This change reworks the TLS support to do a few things:
1) Assign a default port of 636 (the LDAP TLS port) if an explicit port

   was not provided and TLS was enabled.
2) Assume TLS if the port is 636 (even if TLS is not enabled -- mostly

   intended for DNS-based AD domain controller lookup).
3) Specifically opt into LDAP 3, which should be safe for modern usage

   (and we opt into it for the standard LDAP backend). This is

   documented as being the default anyway, but it's better to opt into

   it.
4) Use ldaps:// when TLS is enabled.
5) Avoid calling start_tls_s(), which may not be required for ldaps://

   URLs (and appears to cause errors stating that TLS has already been

   started with ldaps://). Based on other python-ldap examples for

   Active Directory, it seems this should not be required.

Unit tests passed.
Tested this with a customer using TLS, with and without an explicit

port configured. Tested that start_tls_s() failed with a ldaps://

URI and that TLS support worked with ldaps:// without start_tls_s().