Support empty keys in block and flow mappings

[sndth]

This PR fixes #557.

An empty key was only handled at the very start of a document, and it produced an entry whose key
is an empty string. Everywhere else the key separator was rejected, and inside a flow mapping it
was ignored, which dropped the entry:

key: value
: empty key                  # parse_error: Detected invalid indentation
- : foo                      # parse_error: mapping key should not be empty
{ key: value, : empty key }  # parse_error: The ":" mapping value indicator must be
                             # followed after a mapping key

The change

add_empty_key_entry() adds an entry with a null key and moves to the token after the separator.
It is called wherever a key separator turns up with no key before it: at the document root, at the
start of a line in a block mapping, in a block sequence entry, and in a flow mapping. The
deliberate mapping key should not be empty rejection for block sequence entries is gone.

The value of an empty key can be omitted too, so the helper also moves back to the parent mapping
when the following token is not indented deeper - the same rule a normal key already follows:

:
foo: bar
# -> {null: null, foo: bar}

:
  foo: bar
# -> {null: {foo: bar}}

input	before	after
": foo"	{"": foo}	{null: foo}
":"	{"": null}	{null: null}
"key: value\n: empty key"	parse_error	{key: value, null: 'empty key'}
":\nb: 1"	parse_error	{null: null, b: 1}
"- : foo"	parse_error	[{null: foo}]
"{key: value, : empty key}"	parse_error	{key: value, null: 'empty key'}
"\"\": foo"	{"": foo}	unchanged, a quoted key stays a string

Breaking change

As you noted in #553, an empty key is now a null node rather than an empty string, so code reading
such an entry as node[""] has to read node[nullptr] instead. Two existing subcases in
test_deserializer_class.cpp asserted the old behavior and are updated here. I did not touch any
version macro, assuming the v0.5.0 bump happens at release time as usual.

---

Pull Request Checklist

Read the CONTRIBUTING.md file for detailed information.

• Changes are described in the pull request or in a referenced issue.
• The test suite compiles and runs without any error.
• The code coverage on your branch is 100%.
• The documentation is updated if you added/changed a feature.

Please don't

• The C++11 support varies between different compilers and versions. Please note the list of supported compilers. Some compilers like GCC 4.7 (and earlier), Clang 3.3 (and earlier), or Microsoft Visual Studio 13.0 and earlier are known not to work due to missing or incomplete C++11 support. Please refrain from proposing changes that work around these compiler's limitations with #ifdefs or other means.
• Please refrain from proposing changes that would break YAML specifications. If you propose a conformant extension of YAML to be supported by the library, please motivate this extension.
• Please do not open pull requests that address multiple issues.

[coveralls]

Coverage Report for CI Build 32262347650

Coverage remained the same at 100.0%

Details

• Coverage remained the same as the base build.
• Patch coverage: 48 of 48 lines across 1 file are fully covered (100%).
• No coverage regressions found.

Uncovered Changes

No uncovered changes found.

Coverage Regressions

No coverage regressions found.

---

Coverage Stats

Relevant Lines:	5370
Covered Lines:	5370
Line Coverage:	100.0%
Relevant Branches:	1532
Covered Branches:	1532
Branch Coverage:	100.0%
Branches in Coverage %:	Yes
Coverage Strength:	1717.33 hits per line

---

💛 - Coveralls

[sndth]

I added the ? : patch here as a second commit.

The reasoning follows yours: ? introduces an explicit key, and a : on the same line belongs to
the contents of that key rather than to the entry the key is part of. So that separator now turns
the key node into a mapping and adds an entry with an empty key to it, exactly the way a scalar
does in ? foo: bar. Two follow-on adjustments were needed: the separator which later terminates
the explicit key has to find its context below the ones the key's own contents left on the stack,
and completing a pending explicit key at the end of a document has to unwind those contexts too.

input	before	after
? :	{null: null}	{{null: null}: null}
? : foo	{foo: null}	{{null: foo}: null}
? foo: bar	{}	{{foo: bar}: null}
? : / : baz	parse_error	{{null: null}: baz}

The last two rows come along for free, and I think they are worth pointing out: ? foo: bar was
silently dropping the entire entry, and ? : followed by : baz was rejected. Both reproduce on
develop without either commit of this PR, so they are pre-existing rather than something the
first commit introduced.

I'll open the two issues you suggested, for an omitted value in a flow mapping ({foo: }) and for
single pair mappings in a flow collection ([foo: 1]), and link them here.