Support Duck-typing in `filter` predicate

[Acaccia]

The interpreter allows this kind of expression:

(define-private (foo (a (response int bool))) (and (is-ok a) (< (unwrap-panic a) 100)))
(define-private (bar (a (response int uint))) (and (is-ok a) (> (unwrap-panic a) 42))) 

(filter bar (filter foo (list (ok 1) (ok 50))))

Here we filter two times on a list which is inferred to have the type (list 2 (response int NoType)).
However, in the interpreter, the type of the list is inferred after the first call to filter to (list 2 (response int bool)), so the second call to filter fails as it expects another type for the list element.

We need to find a way to support this.

UPDATE: "The Workaround" also has a fix for fold, so it might need the same kind of adaptation for it too.

[obycode]

This is the kind of thing that I would be fine with diverging from the interpreter for. We planned to roll out clarity-wasm with a hard fork any way in case there are unexpected differences. The downside is that if any of those differences show up on chain, then we would not be able to use clarity-wasm to speed up booting from genesis, using the clarity-wasm before that hard-fork.

[Acaccia]

@obycode We cannot ignore this issue. Currently, some valid contracts won't run on Clarity-wasm because of the typechecking of filter. We had to come with this workaround to make things work, but it's not even foolproof yet (see #492).
To make all contracts work, we can either fix this issue, or we can rewrite a second typechecker from scratch. This issue is way easier I believe.

[obycode]

You're definitely more familiar with it than I am currently, so I defer to whatever you think. I just thought that previous problems with the type checker were at least logically consistent. In this case, it seems like it would be reasonable to mark the expression as type (response int bool) and report a type error when it tries to cast it to a (response int uint).