fix: exclude decorators from GetFunctionHeadLoc reported range

[fansenze]

Summary

GetFunctionHeadLoc is supposed to mirror typescript-eslint's
getFunctionHeadLoc, which explicitly skips leading decorators on
MethodDefinition / PropertyDefinition when computing the reported
head range. The old implementation used node.Pos() / TrimNodeTextRange
directly, and in tsgo that sits before the first decorator — so any
rule using this helper (explicit-function-return-type, require-yield,
accessor-pairs, no-misused-promises) reported the decorator line/column
instead of the method/property itself.

Concretely, for

```ts
class HookLifeCycle {
@LifecycleHook()
async didLoad() { ... }
}
```

ESLint reports line 4 col 3 (at async); rslint reported line 3 col 3
(at @LifecycleHook).

Fix: new nodeStartSkippingDecorators helper walks node.Modifiers()
to find the last decorator and starts the range at the next token.
It is plumbed through every branch of GetFunctionHeadLoc where the
"start" came from the decorated node or its property parent.

Related Links

n/a

Checklist

• Tests updated (or not required).
• Documentation updated (or not required).

[gemini-code-assist]

Code Review

This pull request updates the GetFunctionHeadLoc utility to exclude leading decorators from the reported range of class members, aligning the behavior with typescript-eslint. A new helper function nodeStartSkippingDecorators was introduced, and existing tests for require_yield and explicit_function_return_type were updated to reflect the adjusted reporting locations. A review comment suggests initializing the search position for function parameters from the start of the node after decorators to avoid incorrectly matching parentheses within decorator factories.