Support STL implementations without ios

[mtnpke]

I'm working with EASTL as STL implementation, which does not implement ios. <gsl/pointers> includes iosfwd to be able to define operator<< for not_null, so I presently cannot use these features. It would be useful to be able to disable the generation of this operator so that the GSL can work without iostreams.

[SloppyJaconda]

We don't officially support EASTL. However, if you would like to create a PR which adds support for EASTL, I will gladly review it.

[mtnpke]

I'd be glad to, however EASTL is not a drop-in STL implementation. It does not declare anything in the std namespace; I use custom forward headers to achieve this. So it wouldn't really be possible for GSL to "support" EASTL in that kind of way.

What I'm proposing is a define to disable the usage of ostream, which would not only benefit EASTL but also the general case that you are e.g. on an embedded platform where no implementation of iostreams is available (and not desired in the first place). Would that be acceptable?

[JordanMaples]

I'll propose another PR to solve this issue that removes the ostream operator entirely. The thought is that the shape of not_null should somewhat mimic unique_ptr or shared_ptr. Neither of them offer stream operators, so it should be removed.

I'll reach out to some of the Core Guidelines editors to get their opinions on which approach is more appropriate.

Edit: correction to previous statement. I forgot that C++20 has a non-member function for both unique_ptr and shared_ptr operator<<

[JordanMaples]

@gdr-at-ms or @hsutter Would you mind taking a look at both #935 and #940 and letting us know which version works better with regards to the Core Guidelines?
If we want to align with unique_ptr and shared_ptr in C++20, we should probably take #935, since that's when operator<< was introduced for both types.

[mtnpke]

Thanks!