Slightly generalize _compute_sparam elision

[Keno]

To catch a case that occurs in FuncPipelines.jl and was causing precision issues in #48066.

[vtjnash]

I wonder if it it may be clearer (and more extensible later) if written this way:

Suggested change

	length(applyTbody.parameters) == length(arg.parameters) || return nothing
	for i = 1:length(applyTbody.parameters)
	if applyTbody.parameters[i] === applyTvar && arg.parameters[i] === tvar
	return LiftedValue(argdef.args[3])
	end
	end
	# find a possible parameter number we are extracting when matching with `tvar`
	i = findfirst(===(tvar), arg.parameters)
	# determine if we can find the apply_type for that parameter
	if applyTvar === applyTbody.parameters[i]
	return LiftedValue(argdef.args[3])
	end

[Keno]

I'm not sure whether we want to look at all the parameters or just the first one. We can probably look at the first one in applyTbody, but I think arg might potentially have multiple instances.

[vtjnash]

First is indeed probably the most common to extract

[aviatesk]

Suggested change

	isa(arg, DataType) || return nothing
	isType(arg) || return nothing
	isType(arg) || return nothing

isType(x) includes isa(x, DataType).

[Keno]

Will do in a follow up

[vchuravy]

@Keno is this backportable? #48612

[Keno]

I'd prefer not to. It's possible there further commits afterwards that are required

[dpinol]

@Keno Maybe in julia 1.9.1? #48612 shows that the impact is not negligible

[KristofferC]

This has the backport label but @Keno says it shouldn't be backported. @vchuravy and @Keno, could you sort it out what it will be between yourself :P.