Don't let the XML input archive destructor throw at end of input

[gennaroprota]

An XML input archive whose stream reaches end of input during windup() (run from the destructor) no longer throws, which, from an implicitly noexcept destructor, was calling std::terminate/abort.

Root cause

windup() calls my_parse(). Boost 1.66 (commit 64dc620, whose real purpose was dropping a <codecvt> dependency) changed my_parse() from returning false on a stream fail() to throwing input_stream_error:

is.get(result);
if(is.fail())
    return false;      // <= 1.65
// vs
if(is.fail())
    throw ...;         // 1.66+

get() sets both failbit and eofbit at end of input, and the check tested fail() before eof(). So simply reaching the end while scanning for a tag threw; and since that happens inside the destructor's windup(), the exception escaped the noexcept destructor and terminated the process.

The close tag can be absent at that point for several reasons, which is why this surfaced as three separate reports:

• A truncated stream: ~xml_iarchive throws exception when input stream is almost empty #99.
• An archive whose writer was never flushed (so the close tag was never written): xml_iarchive destructor calls abort() #82.
• A well-formed archive whose close tag an earlier failed read already consumed (e.g. probing for an nvp that isn't there) : xml_iarchive in broken state after archive_exception is thrown #109.

Issues

Fixes #99 (same root cause as the already-closed #82).

It also removes the process-terminating crash reported in #109, but not that issue's broader "broken state after an exception": a failed read still consumes input and leaves the archive unusable, which is a separate, by-design limitation of the forward-only positional parse (you can't probe for an absent named element without consuming input). So this only refs #109 rather than closing it; we can later decide whether #109 should be closed as "crash fixed, remainder by design" or kept open.