Use TypeId to identify subscription::Map

[hecrj]

This PR fixes #2236. The idea here is to use the TypeId of a closure instead of the hash of a function pointer in subscription::Map, which I am assuming is more stable.

Coincidentally, this also introduces closure support for Subscription::map!

[snaggen]

I also had to add

diff --git a/winit/src/application.rs b/winit/src/application.rs
index 9cd992f4..99c7a666 100644
--- a/winit/src/application.rs
+++ b/winit/src/application.rs
@@ -830,7 +830,7 @@ where

 /// Updates an [`Application`] by feeding it the provided messages, spawning any
 /// resulting [`Command`], and tracking its [`Subscription`].
-pub fn update<A: Application, C, E: Executor>(
+pub fn update<A: Application + 'static, C, E: Executor + 'static>(
     application: &mut A,
     compositor: &mut C,
     surface: &mut C::Surface,

to my local libcosmic tree for it to build. But with that compile fix things seems to work

[snaggen]

I assume using TypeId will change the semantics slightly, that will only update the subscription if the closure is changed in such a way that the type changes. If you change the closure in such a way that the type is still the same, the subscription will not be updated. So, if is desired to have this kind of functionality, maybe an explicit id like in the subscription::channel function is preferred. That would break the API though. So, not sure what is better, change the semantics or break API.

[hecrj]

I assume using TypeId will change the semantics slightly, that will only update the subscription if the closure is changed in such a way that the type changes.

Technically yes, but it should work as expected with function item types; which is the intended way to use the API here.

It'd be great to be able to restrict the closure to function item types, but I don't think that's possible in Rust yet.

[snaggen]

In that case, I say, just document it and ship it :)