Fix bug with auto replacing components in compositor

[sudormrfbin]

This was last known to be working with 5995568 at the time of commit, but now doesn't work with latest rust stable.

The issue probably stems from using std::any::type_name() for finding a component in the compositor, for which the docs explicitly warn against considering it as a unique identifier for types. replace_or_push() takes a boxed Component and passes it to find_id() which compares this with a bare Component. type_name() returns Box<T> for the former and T for latter and we have a false negative. This has been solved by using a generics instead of trait objects to pass in a T: Component and then use it for comparison.

I'm not exactly sure how this worked fine at the time of commit of 5995568; maybe the internal implementation of type_name() changed to properly indicate indirection with Box. Ideally we can use some other mechanism which doesn't depend on type_name().

[archseer]

But if an ID is specified, we use that instead of the type name? All popups already use a custom id. The type name is only a fallback on components that don't expose an id

[sudormrfbin]

Ah we use both the id and type name instead of just the id for find_id:

helix/helix-term/src/compositor.rs

Line 227 in 40eb126

.find(|component| component.type_name() == type_name && component.id() == Some(id))

I changed it now to only use the id.

find_id() filters a list of boxed components to find the component with the given id, but it still needs to downcast it into a concrete component type like Popup to return it. So I kept around the type parameter in replace_or_push() instead of reverting it into the old behavior of using a trait object.