fix(windows): do not panic when transitioning from Destroyed

[thomaseizinger]

We are seeing crash reports from Tauri applications caused by this particular panic. I am not sure what they are caused by but it seems save to just remove the panic, log a message and leave the state in Destroyed instead.

Resolves: #1180

[github-actions]

Package Changes Through 8962da6

There are 1 changes which include tao with patch

Planned Package Versions

The following package releases are the planned based on the context of changes in this pull request.

package	current	next
tao	0.34.5	0.34.6

Add another change file through the GitHub UI by following this link.

---

Read about change files or the docs at github.com/jbolda/covector

[Legend-Master]

I am in favor of this, maybe we could discuss with the winit maintainers about the reasoning behind this before merging though (or we should identify the reason we reached this line if this is an internal state error that should not happen and the panic is the right thing to do)

[Legend-Master]

After a closer look at the current code, we only ever move the state to destroyed on run_return ends (which has a reset call follows it immediately) and on WM_ENDSESSION

For the run_return case, it seems to me that it's impossible to trigger this panic since we only receive events on the main thread and since we reset the states immediately, this should not happen
For the WM_ENDSESSION case, the fix should be #1157 instead of this

[thomaseizinger]

For the run_return case, it seems to me that it's impossible to trigger this panic since we only receive events on the main thread and since we reset the states immediately, this should not happen

We are using run_return in our application FWIW.

[Legend-Master]

We are using run_return in our application FWIW.

run also uses run_return internally, since the state is reset to Uninitialized in literally next line, I don't think it's possible to hit (unless we did some other violations like calling move_state_to in another thread)