mockserver: stack-allocate TagProcessor in tests

Tests created their TagProcessor via MockServer::createProcessor(),
which returned a unique_ptr. Lambdas captured that unique_ptr by
reference and called processor.get() when they fired later.

libc++'s std::unique_ptr::reset() nulls the stored pointer before it
invokes the deleter. So while ~TagProcessor() blocked in
waitForTagCompletion(5s), the TagProcessor object itself was alive (that
is the whole reason it waits, since Finish completions are expected to
arrive after the client has already finished) yet processor.get() read
through the unique_ptr already returned nullptr. Any callback that
constructed a new tag in that window forwarded the null into
AbstractTag and crashed on processor->registerTag(this).

The previous workaround captured processor.get() up front at a single
call site. Every test in this file (and in the interceptors test)
followed the same [&] / processor.get() pattern, so the possibility for
a crash existed at every call site. This flaky behavior got observed in
recent CI runs.

Drop MockServer::createProcessor() and stack-allocate TagProcessor:

    TagProcessor processor(m_server.get());

The address of a stack object is stable for its entire lifetime,
including while its destructor runs, so &processor in a callback is
always a valid TagProcessor*. There is no smart-pointer indirection
left to lie about the pointee.

Pick-to: 6.12
Change-Id: Iebec19bce57879778b2b5a5c0e94ce00ca62945d
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>