将SocketSSLContext对象的创建职责交给end users

**Is your feature request related to a problem? (你需要的功能是否与某个问题有关?)**
从当前brpc代码支持ssl功能的实现上看，brpc框架本身承担了创建SSL_CTX对象的职责。
然而基于SSL本身的options非常的多，各个用户对于SSL的options要求也不一样以及同时SSL的版本也在不断更新等理由，
导致brpc支持ssl功能代码难以具备普遍性，无法适应新的变化

这个issue https://github.com/apache/brpc/pull/2251 就是一个直接的例子。

**Describe the solution you'd like (描述你期望的解决方法)**
我认为SSL_CTX对象的创建职责应该交给用户，rpc框架只负责SSL_CTX enable的情况下
做正确的handshake 和 TLS 读写功能即可：

client:
```
SSL_CTX* ctx = createSomeSSLcontext();
brpc::ChannelOptions options;
options.sslcontxt = ctx;
channel.Init(server.c_str(), load_balancer.c_str(), &options) != 0)
```

server:
```
SSL_CTX* ctx = createSomeSSLcontext();
brpc::ServerOptions options;
options.sslcontxt = ctx;
brpc::Server server;
server.Start(port, &options)
```

**Describe alternatives you've considered (描述你想到的折衷方案)**
NA

**Additional context/screenshots (更多上下文/截图)**
NA

Start by reading the current SSL_CTX creation, handshake, and TLS read/write paths for both ChannelOptions and ServerOptions, then compare the related PR 2251. Done means client and server accept user-created SSL_CTX objects while brpc still performs the handshake and TLS I/O correctly.

Written by the indexing model from the issue text.