Propose two new options for building

[micl2e2]

This patch is proposing two new build flags: TD_BUILD_BENCHMARK and TD_BUILD_TESTING, both for the ability of enabling/disabling corresponding submodule's building and running.

The major rationale is that, for some downstream projects that use tdlib as an in-tree dependency(rather than installed one), building the project means building the tdlib, and testing the project means testing the tdlib. While benchmarks and tests are essential submodules, it is not to be distributed to the end users. so in some cases where a downstream has full confidence for the quality of current tdlib's codebase, during a frequent edit-build-debug cycle, it is sensible to disable these two submodules, which could potentially help a third-party app gain a even smoother development experience, which fullfills the very first goal introduces at https://core.telegram.org/tdlib.

Here are some benefits we could gain:

1. Storage Saving: Considering the storage occupation just under build dir, skipping these two modules would be undoubtedly significant savings:

# Release
...
2M  build/tdutils
45M  build/benchmark
45M  build/test
114M  build/CMakeFiles
404M  build/

# Debug
...
59M  build/tdutils
529M  build/test
869M  build/benchmark
1.3G  build/CMakeFiles
4.9G  build/

And for some downstream projects that use tdlib as an in-tree dependency, the build would be located in those projects' root or somewhere else if their any special preferences.

2. Time Saving: Building durations of these two are already quite short, but the executions of them are the combination of many cpu-intense, network-dependant tasks, especially for tests:

real	6m47.718s
user	11m33.489s
sys	6m53.766s

at least some minutes required for a relatively performant machine, and they are the cases where cache tools like ccache won't provide any help. These additional time won't be recognized by installed-tdlib downstreams, but in-tree-tdlib downstreams, who have their own tests and also use cmake's testing workflow to run the tests. While CTest already provides a builtin BUILD_TESTING switch, it is for more general cases, switching off it means switching off project's all ctest-based tests, not just tdlib's ones, so a dedicated option would help to customize tests running according to downstreams' special needs. And those new added options are ON by default to make behaviors consistent.