refactor(solid-query): replace Accessor<T> wth FunctionedParams<T>

[braden-w]

I'd like to open a discussion about replacing FunctionedParams<T> with solid-js's built in Accessor<T> in our codebase, which would reduce cognitive overhead for developers.

First, I just wanted to acknowledge that I see the argument for keeping FunctionedParams<T>—it's used in a specific context that Accessor<T> is not necessarily used for, and there is a specificity communicated in its name. We know that any place FunctionedParams is mentioned typically wraps some sort of option or configuration.

That being said, I thnk the contextual value of name "FunctionedParams" over "Accessor" is the only reason this utility type should exist. SolidJS already provides Accessor<T> type with the exact same type signature. Typescript is a structurally typed language, and so there are fewer benefits of using two types with identical type signatures that are only different in name. Having an identical FunctionedParams<T> doesn't add any extra type clarity.

The separate naming isn't just neutral, but I believe "FunctionedParams" would be more confusing than just using "Accessor" for most developers.

• Cognitive overload/another unnecessary abstraction to memorize: Developer experience when jumping to definition, the name is unfamiliar and requires them to jump to the definition of FunctionedParams<T> = () => T. It's unnecessary complexity without providing additional clarity, and another repo-specific concept they need to memorize.

• The name is misleading. On first glance, the term FunctionedParams might suggest parameters being transformed, which isn't what's happening—we're simply accessing values through functions.

• Name is redundant. FunctionedParams typically used in contexts where it's already clear we're dealing with parameters (e.g., in function signatures), making the "Params" suffix unnecessary.

options: FunctionedParams<CreateQueryOptions<T>> // verbose and unfamiliar, requires me to jump to FunctionedParams
options: Accessor<CreateQueryOptions<T>>         // clear and uses existing terminolgy

With Accessor, we can use a type that consuming developers are already familiar with and match established patterns in SolidJS, reducing cognitive overhead for developers.

Are there specific cases where FunctionedParams provides better clarity? I think we should either:

1. Replace all instances of FunctionedParams<T> with Accessor<T>
2. Update the definition so type FunctionedParams<T> = Accessor<T>