[WinEH] Miscompilation due to inlining of unterminated try scopes

When inlining functions in C++ files compiled with -EHa try scopes can be mistakenly leaked over to the caller:
https://godbolt.org/z/8Gbqd6Gha

This can sadly not be executed in godbolt itself but we can see the issue when looking at the exception information for `?test@@YAHH@Z`:
Labels `.Ltmp14` to `.Ltmp12` are referenced in the `ip2state` map and declare a unwinding region with state 0.
`tryMap` + `handlerMap` are describing that an exception occuring in the region has the unwind destination `?catch$3@?0??test@@YAHH@Z@4HA`.
This unwind destination can be clearly identified as the catch clause of `ExitOnThrow`.
The region (`.Ltmp14` to `.Ltmp12`) also erroneously contains the call to `DoThrow` which should not be covered by the try scope of `ExitOnThrow`.

When compiling this with MSVC we get the correct returncode 3:
https://godbolt.org/z/Y6q1f8rY4

When compiling this with clang-cl (trunk) locally we get the false returncode 2 instead.

Start with the two Godbolt reproductions and clang-cl's WinEH inlining path; compare the generated exception information for `?test@@YAHH@Z`, especially the `ip2state`, `tryMap`, and `handlerMap` entries. Done means the inlined `DoThrow` call is no longer covered by `ExitOnThrow`'s try scope and clang-cl produces the expected return code 3.

Written by the indexing model from the issue text.