[C++] pulsar-client-cpp stability enhancements and code cleanup

Howdy! My company is investing heavily into event driven workflows, and we're utilizing Pulsar to accomplish this end. We're primarily a C++ shop, and I'm a Principal Engineer and in charge of the integration of Pulsar into our system, and experienced in C++. I've made a few bug fixes to the C++ client already, and in doing so I've noticed that it could use a bit of love to bring greater consistency to the design and fix up some low-hanging fruit. We've integrated Pulsar into our own build system, and it required a lot of changes to pass our build (which uses many more warnings and runs tests with ASAN). We've found that enforcing a more strict set of warnings helps to keep a c++ codebase healthy and stable, and I'd like to upstream these changes for the benefit of everyone, and to make continued maintenance easier.

Would anyone be opposed to me undertaking some general cleanup of the C++ client?

My proposed TODO list:

- Enable many more warnings (`-Wall`, `-Wvla`, `-Wformat-security`, etc)
- Enforce warnings as errors to prevent changes being submitted with warnings
- Fix all the subsequent warnings that will be generated
- Fix compatibility with boost 1.41 (the documentation claims it should be compatible, but it's not, and that happens to be the version we're stuck on).
- Use consistent format for `#include`s of local files (some have a `/lib` prefix, others don't)
- Run the tests via ASAN or Valgrind, if available (not sure how easy this will be yet...)
- Update syntax to take advantage of more C++11 features (like `std::make_shared`, move semantics, etc)

I'll obviously split this stuff up into a series of smaller changes. I'm hopeful that by doing this I'll gain more experience working with Pulsar and could potentially contribute more significant improvements in the future, i.e. performance enhancements and helping to keep feature parity between the C++ and Java clients.

Thanks!

该提案涵盖 C++ 客户端构建、警告、Boost 1.41 兼容性、include 格式化、测试以及 C++11 更新，但没有列出具体文件或测试。首先检查当前的构建配置和测试设置，然后将 TODO 列表拆分为一个范围明确的变更，并明确受影响的文件和验证标准。

由索引模型根据 Issue 内容生成。