Provide C or/and envvar interface to global_control

[anton-malakhov]

Problem

As TBB is getting adopted wider as a composable parallelism solution outside of traditional C++ world, the need is growing in controlling its global settings for applications, which are not written in C++. For example, MKL (which has TBB threading layer) is a library with C interface and as such is used in C applications and libraries. In turn, MKL is used in many other languages and libraries, for example, Numpy and Julia. They don't necessary know or want to know anything about how threading is implemented and what is the user's choice of the threading layer at run-time while users&applications don't want to complicate their simple application scripts with a C++ code that interacts with TBB's global_control class. They all need a simpler way to interact with TBB's global settings. For C-based projects like Numpy and Julia-lang, there should be a way to control TBB's behavior in their sub-components using a C API. For scripting languages, the function names and usage model should be friendly to use with dynamic loading of C symbols like it is for TBB_runtime_interface_version(). For Python, the tbb4py module provides a way (mostly) for a user or Python scripts to control TBB's global behavior. However, many projects do not have direct dependence on TBB, e.g. Numpy optionally depends on MKL, which in turn optionally depends on TBB, thus it doesn't want to introduce tbb4py as their hard-coded requirement. So, their ideal solution would be introduction of environment variables to control TBB defaults directly the same way as sklearn/joblib/loky suggests to do it for other threaded libraries: https://github.com/numpy/numpy/issues/11826#issuecomment-437291454. Environment variables allow to avoid complications with detection and dynamic loading of TBB symbols by passing global settings 'just in case' if TBB will be loaded later. Semantics of both global_control and envvars is global anyway and thus it looks quite natural to initialize global_control's with default values from environment variables. Suggestion to introduce environment variables in applications/libraries, which use TBB directly, just introduces more problems than it solves. For example, MKL has these variables but it might not be the only component, which uses/controls TBB in an application, the other popular library, which uses TBB directly and co-exists along with Numpy is Numba. Thus having no single point of controlling TBB settings leads to conflicts between independent components, which implement such control themselves.

Proposals

1. Implement pure C interface for all the global_control settings but possibly limited to single scope in order to avoid complications with life time and scope where settings are effective. So that it will be friendly with dynamic loading and manipulating settings in a single function, w/o the need to release the scope later.
2. Complementary/independent from p1 suggestion. Implement a set of environment variables which provide initial default values for global_control settings: TBB_NUM_THREADS and TBB_STACK_SIZE