`solid/reactivity` hardcodes the assumption that solid primitives are imported from `"solid-js"`

[Alloyed]

Describe the need
semi-related to: solidjs/solid-refresh#44
In our codebase, we use a universal renderer that explicitly skips the web-specific features present in "solid-js". this means, instead of writing import {createSignal} from 'solid-js', we write import {createSignal} from 'my-custom-solid-renderer';

This kind of accidentally worked in earlier versions of eslint-plugin-solid, but it seems that in-between 0.13.2 and 0.14.5, the symbol detection got more strict, leading to many more false negatives.

Suggested Solution
some kind of config option to specify the import path, eg. solidImportPattern: /^my-custom-solid-renderer/
this would involve adding a parameter to the trackImports() method and adding this config flag to every rule that uses it. (I don't know eslint that well, but if this could be a global parser flag ala the tsconfig that would probably be better)

https://github.com/solidjs-community/eslint-plugin-solid/blob/main/packages/eslint-plugin-solid/src/utils.ts#L149

Possible Alternatives
the upstream solid package could be refactored to not be web-specific, or for the reactive pieces to exist in their own library (solidjs/solid#2051). i think this is already happening for solid 2.

we could remove the requirement altogether that imports come from the solid-js library, but i think that would be worse for all other users.

• I would be willing to contribute a PR to implement this feature