Stream read/write with generated locales defaults to classic format/parse

I've just seen that the default flag for stream operations with locales generated by Boost.Locale is `posix`, i.e. "classic".

This leads to the bug/inconsistency I've encountered at https://github.com/boostorg/locale/issues/64#issuecomment-873570242

Assume this:

```
std::locale::global(boost::locale::generator{}("de_DE"));
external_func(); // Some other library not aware of Boost.Locale
```

And then:
```
std::string external_func(){
std::cout << "Enter 1 + " << 123.25 << std::endl;
float num;
std::cin >> num;
std::ostringstream os; // Uses global-locale
os << num;
return os.str();
}
```

So although a German locale is globally set and one can reasonably expect that all formatting and parsing is done with the German decimal separator `","` this is not the case: It will use the classic locale which outputs `"123.25"` and entering `"124,25"` will be parsed as `"12425"` if it doesn't fail.

I traced this to `base_num_format/base_num_parse` which access the `ios_info.display_flags()` of the stream which defaults to `posix`

So one would need to do `outstream << as::number` and `instream >> as::number` first for every stream created which external libraries are not aware of leading to those issues.

Hence I'd change the default from `posix` to `number` so results are more intuitive and external libraries unware of Boost.Locale work.

Although I'd consider this a bugfix, this is a breaking change, hence I wanted to make sure I didn't miss anything.

But the described behavior really does sound like a bug to me, see also https://github.com/boostorg/locale/issues/64#issuecomment-873570920: Imagine an external library unaware of Boost.Locale using the global locale and inspecting the `numpunct` facet and then find that formatting/parsing doesn't behave as expected.