Memory leaks when application is compiled with BOOST_DISABLE_THREADS

There's a memory leak if an application is compiled with BOOST_DISABLE_THREADS, is this expected behaviour?

test.cc:
``` c++
#include

int main(int argc, char *argv[]) {
boost::program_options::options_description opts{"Test"};
opts.add_options()
("help,h", boost::program_options::bool_switch(), "display this help and exit");

return 0;
}
```

Without `BOOST_DISABLE_THREADS` defined:
```
$ g++ -fsanitize=address test.cc -lboost_program_options -lboost_system -o test
$ ./test
$
```

With `BOOST_DISABLE_THREADS` defined:
```
$ g++ -fsanitize=address -DBOOST_DISABLE_THREADS test.cc -lboost_program_options -lboost_system -o test
=================================================================
==97000==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 24 byte(s) in 1 object(s) allocated from:
#0 0x7f6757a39458 in operator new(unsigned long) (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xe0458)
#1 0x7f675771777f in boost::program_options::options_description_easy_init::operator()(char const*, boost::program_options::value_semantic const*, char const*) (/usr/lib/x86_64-linux-gnu/libboost_program_options.so.1.65.1+0x3f77f)

Indirect leak of 176 byte(s) in 1 object(s) allocated from:
#0 0x7f6757a39458 in operator new(unsigned long) (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xe0458)
#1 0x7f6757732624 in boost::program_options::bool_switch(bool*) (/usr/lib/x86_64-linux-gnu/libboost_program_options.so.1.65.1+0x5a624)

Indirect leak of 120 byte(s) in 1 object(s) allocated from:
#0 0x7f6757a39458 in operator new(unsigned long) (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xe0458)
#1 0x7f6757717761 in boost::program_options::options_description_easy_init::operator()(char const*, boost::program_options::value_semantic const*, char const*) (/usr/lib/x86_64-linux-gnu/libboost_program_options.so.1.65.1+0x3f761)
#2 0x7f6756d67b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)

Indirect leak of 27 byte(s) in 1 object(s) allocated from:
#0 0x7f6757a39458 in operator new(unsigned long) (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xe0458)
#1 0x7f67577155fc (/usr/lib/x86_64-linux-gnu/libboost_program_options.so.1.65.1+0x3d5fc)

Indirect leak of 24 byte(s) in 1 object(s) allocated from:
#0 0x7f6757a39458 in operator new(unsigned long) (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xe0458)
#1 0x7f6757716593 in boost::program_options::option_description::option_description(char const*, boost::program_options::value_semantic const*, char const*) (/usr/lib/x86_64-linux-gnu/libboost_program_options.so.1.65.1+0x3e593)

Indirect leak of 16 byte(s) in 1 object(s) allocated from:
#0 0x7f6757a39458 in operator new(unsigned long) (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xe0458)
#1 0x7f67577326c5 in boost::program_options::bool_switch(bool*) (/usr/lib/x86_64-linux-gnu/libboost_program_options.so.1.65.1+0x5a6c5)

SUMMARY: AddressSanitizer: 387 byte(s) leaked in 6 allocation(s).
```

Start by compiling the supplied test.cc both with and without BOOST_DISABLE_THREADS, using the shown AddressSanitizer command, and compare the leak reports. Trace the allocations reported through program_options::options_description_easy_init and bool_switch; done means explaining whether the macro causes the leak and correcting it without introducing leaks in either build.

Written by the indexing model from the issue text.