noexcept correctness: stop lying about moves, start promising the rest

[martinus]

Fixes #63, plus an audit of every other method.

1. The move operations promised something they cannot keep

std::vector can declare its move noexcept unconditionally because it only steals a pointer. An svector in direct mode has to relocate the inline elements, which runs T's move constructor. Claiming noexcept anyway meant a throwing move called std::terminate, and — worse — std::move_if_noexcept asks exactly this trait, so growing a std::vector<svector<T>> moved instead of falling back to copy and turned push_back's strong guarantee into an abort.

Both are now noexcept(std::is_nothrow_move_constructible_v<T>). boost::container::small_vector is conditional here for the same reason:

boost small_vector<std::string,4>  nothrow_move = 1
boost small_vector<ThrowingMove,4> nothrow_move = 0

Nothing ordinary is affected — std::string, std::vector, std::unique_ptr, anything trivially copyable all keep the answer they had.

2. A leak, found by testing the above

Once a throwing-move type could actually be tested, asan immediately caught this:

Direct leak of 96 byte(s) in 1 object(s) allocated from:
    #1 in alloc                          svector.h:171
    #2 in emplace_back_grow<int const&>  svector.h:323
    #3 in emplace_back<int const&>       svector.h:830

Growing allocates new storage, builds the new element into it, then relocates the existing elements. If T's move constructor throws partway through that relocation, the new storage was owned by nothing yet and the already-built element was never destroyed — both leaked. take_over_storage() now frees them on the way out.

This is pre-existing and only reachable with a throwing move, which is precisely why the unconditional noexcept kept it hidden.

3. Everything else was missing noexcept entirely

Probing svector<std::string, 4> against std::vector<std::string> before this PR: every entry except the two move operations answered 0 where std::vector answered 1 — size(), capacity(), empty(), max_size(), data(), all eight iterator accessors, operator[], front(), back(), clear(), pop_back(), swap(), and the default constructor.

None of them can throw; they simply never said so. After this PR the two contracts are byte-identical:

$ diff <(probe svector) <(probe std::vector) && echo IDENTICAL
CONTRACT IDENTICAL to std::vector

swap() is the one that needed thought — it is a move construction plus two move assignments, so it takes the same condition as those.

Left alone deliberately: at() throws out_of_range by design, shrink_to_fit() allocates. Both match std::vector in still being able to throw.

Tests

New test/unit/noexcept_contract.cpp. The contract assertions compare against std::vector rather than a hardcoded expectation, so the two cannot drift apart, and the macro stringifies the member so a failure says which one:

error: static assertion failed: clear()

Plus four runtime cases: a throwing move now unwinds instead of terminating (construction and assignment), an indirect move still never touches the elements, std::vector growth keeps the strong guarantee, and the leak above is caught under asan.

Verified green with gcc and clang under -fsanitize=address,undefined. Benchmarked the growth path A/B — the added try/catch costs nothing measurable, as expected for table-based EH.