[GOBBLIN-2267] Block GobblinYarnAppLauncher launch() until the YARN application is terminal (#4203)

GobblinYarnAppLauncher.launch() returned as soon as the YARN application
was submitted while the status monitor kept polling on a background
non-daemon thread. For the Azkaban submitter path run() therefore
returned at submission time, and the launcher-owned non-daemon threads
(the status monitor, the ServiceManager, the YARN client) kept the JVM
alive for the whole job, so the process hung after run() finished. The
status monitor also called stop() from its own worker thread on a
terminal report, which then awaited termination of its own executor and
stalled for the full timeout.

Add a CountDownLatch that the status monitor releases once the
application reaches a terminal state (or the launcher is otherwise
stopped, e.g. lost AM visibility). In attached mode launch()/run() blocks
on the latch and then runs stop() on the calling thread, so teardown
shuts the (non-daemon) monitor and the launcher services down before
launch() returns: no launcher-owned thread is left to keep the JVM alive,
and stop() no longer runs on the monitor thread, removing the
self-shutdown stall. Detached launches return right after submission and
are torn down by the monitor as before.

Add unit tests covering that a terminal or lost-AM report releases the
latch without calling stop() on the monitor thread (attached), and that a
detached launch still stops on the monitor thread.

Co-authored-by: pratapaditya04 <adityasingh@linkedin.com>
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>