feat(useExplicitFunctionReturnType): support higher-order function

[kaykdm]

Summary

related: #2017

This PR introduces the ability to detect higher-order functions in the useExplicitFunctionReturnType rule, specifically functions that return other functions.

Limitations:

Nested statement handling is not implemented: The current implementation does not cover cases where functions are returned inside conditional or branching logic (e.g., if statements or switch statements).

Example of unsupported case:

function example() {
    if (condition) {
        return function() {}; // This return inside the 'if' statement is not detected
    }
}

Question:

Should biome support nested statements like if or switch when checking for higher-order functions?
This would involve inspecting return statements within those control structures, adding complexity but potentially broadening the detection capability.

[codspeed-hq]

CodSpeed Performance Report

Merging #4117 will improve performances by 7.61%

_{Comparing kaykdm:support-higher-order-functions (ed3ec30) with main (295efb9)}

Summary

⚡ 1 improvements
✅ 100 untouched benchmarks

Benchmarks breakdown

	Benchmark	main	kaykdm:support-higher-order-functions	Change
⚡	db_17847247775464589309.json[cached]	13.7 ms	12.8 ms	+7.61%

[Conaclos]

Should biome support nested statements like if or switch when checking for higher-order functions?

Isolated Declarations and the ESLint rule seem to recognize these patterns.
However, this could add a lot of complexity to the rule.

I think the reason d'être for allowing higher order function is to simplify the writing of functional code with curried functions. It is fulfilled by checking only body with a single return statement function f() { return function():void {} } or arrow expressions such as () => (): void => {}.

We can still reevaluate this decision once users make the case for it.

[kaykdm]

Should biome support nested statements like if or switch when checking for higher-order functions?

Isolated Declarations and the ESLint rule seem to recognize these patterns. However, this could add a lot of complexity to the rule.

I think the reason d'être for allowing haigher order function is to simplify the writing of functional code with curried functions. It is fulfilled by checking only body with a single return statement function f() { return function():void {} } or arrow expressions such as () => (): void => {}.

We can still reevaluate this decision once users make the case for it.

I agree with you, adding this could introduce a lot of complexity. Since we can always reevaluate later based on user feedback, I think this PR is ready for review.

[Conaclos]

It is good to add examples to demonstrate the exceptions to the rule. However, I think we should also describe the exceptions to the rule in the description (before ## Examples). We should also document the previous exceptions to the rule introduced in your previous PRs.

[Conaclos]

I think we should check only the first statement because we have to report code like:

function f() {
  if (x) {
    return 0;
  }
  return () => {}
}

Don't forget to add a test to avoid any regression here.