type paramenter refinement, future enhancements

[michaellilltokiwa]

We might (later) even introduce a compile_time_panic intrinsic for this that would refuse to create a binary if it is not eliminated when FUIR is created by the monomorphization phase.
What is a little ugly about this solution is that the constraint T : property.equatable occurs twice and that Sequence appears to always be equatable, which is not the case. An alternative would be to add constraint inheritance like

public Sequence(public T type) ref : (if T : property.equatable then property.equatable) is

but this does not make us win a beauty competition either...
Another alternative would be to extend the front end to detect that the redefines is_equatable implies T: property.equatable such that the if T : property.equatable is not needed. But then this analysis becomes harder to implement and the user might get confused about when compile time evaluation is possible and when not (we might even need a comptime modifier à la Zig for is_equatable...).
For now, maybe try the solution above and create issues for the bug that the constraint in the pre else was accepted (see below) and for the possible future enhancements I just outlined.

#3887