Allow extension of details::serializer

[nomadwolf0]

There are several ideas on here related to modifying the dump output. Currently, the only option is to create your own, although much of the hard work was already done in details::serializer. If we could extend it, that'd be great. If we could pass that modified serializer to dump and operator<<.

At minimum, making serializer::dump virtual, and switching some of the private variables & functions to protected would be helpful.
With some additional changes in how the serializer is constructed (notably, supplying the output adapter after construction, within dump or operator<<), this could also help the concerns noted in #4117.

If you have concerns about people mucking with the representation of the non-aggregate types, you can have virtual functions just for the output of objects & arrays.

[nomadwolf0]

OK, I've had time to flesh this out and implement it (& unit test) to, at least, achieve what I wanted to do (essentially the request of #4171), but it can also help for #4131 (I think, I haven't fully thought it through) and #3022. With a little bit of additional change, #2711 can also be resolved.

@nlohmann noted in #3022 that it's difficult to create an API that can handle all of the tweaks people would like in their dump output. Allowing limited modifications to the dump serializer allows everyone to implement their own tweaks. Then the serializer can be passed to dump. Since the serializer is a new interface to the public, the API for the serializer can be constructed from scratch.

For now, I've aimed for minimal changes, but fully realizing this would require further modifications.

For the serializer, I have not made any private members protected, so the various emit_*() functions are the only way for derived classes to write out, and that is limited to white-space and commas. There's also a write_key_colon() that writes out the escaped key string followed by ':'. The goal is to limit how users may break the JSON output to be unparseable or to fail the round-trip, hopefully limiting bug reports here.

New & modified changes to details::serializer: (I only included code for the one-liners).

template<typename BasicJsonType> class serializer {
    virtual ~serialzer() = default

   void set_output_adapter(output_adapter_t<char> s) { o = std::move(s); }

   void emit_newline(const unsigned int indent = 0);  // writes \n, and optionally indents using indent_string
   void indent_line(const unsigned int indent);     // indents using indent_string
   void emit_spaces(const unsigned int count);    // write out spaces, regardless of indent_string contents
   void emit_tabs(const unsigned int count);    // write out \t, regardless of indent_string contents
   void emit_comma() { o->write_character(','); }

   virtual void pretty_print_array(const BasicJsonType& val, ... /* same as dump(), excluding pretty_print */);
   virtual void pretty_print_object(const BasicJsonType& val, ... /* same as dump(), excluding pretty_print */);

Within serializer::dump(), if we are pretty printing, and the value is an array or object, it writes out '[' or '{', and calls pretty_print_(array|object)(). On return, it writes out the closing brace/bracket.
If it is not pretty printed, it remains inside the serializer class, to ensure the output is unchanged from current library (the concern raised in #2526).

Within basic_json, the changes are essentially a few more dump() overloads:

string_t dump(serializer& s,
              const int indent,
              const bool ensure_ascii = false) const;
std::ostream& dump(serializer& s,
                   std::ostream& stream,
                   const bool ensure_ascii = false) const;

In each, the function creates the appropriate output_adapter_t, and sets in the serializer. The only difference for the second overload (compared with operator<<()) is that the fill character is not pulled from the stream, since it is set when the serializer is constructed.

There are some other issues to work out, but I didn't want to go down that rabbit hole if you don't feel this to be a worthwhile path.