Suggestion: Renaming some filters

[joshnuss]

Some of the filter names are very short. Names like .sl(), .sr(), .adj() can be hard to remember what to they do. I think it would lead to clearer and more declarative code if the function names were a bit longer.

Current list of filters: https://supabase.io/docs/client/using-filters

Rename suggestions:

• .cs() -> .contains() or add a json: true option to .in()
• .cd() -> .within()
• .sl() -> .rangeLt() or add a range option to .lt(column, value, {range: true})
• .sr() -> .rangeGt() or add a range option to .gt(column, value, {range: true})
• .nxl() -> rangeGte() or add a range option to .gte(column, value, {range: true})
• .nxr() -> rangeLte() or add a range option to .lte(column, value, {range: true})
• .adj() -> .adjacent()
• .ova() -> .within()
• .fts() -> .textSearch(column, search, {type: 'tsvector'})
• .plfts() -> .textSearch(column, search, {type: 'plainto'})
• .phfts() -> .textSearch(column, search, {type: 'phraseto'})
• .wfts() -> .textSearch(column, search, {type: 'websearch'})

[kiwicopple]

Hmm I quite like this, especially consolidating some of the functions into parameters - it would make for a much nicer DX, and would be easier for new developers.

@soedirgo any thoughts here? If we went down this path we would have to deprecate the old functions with a warning

[soedirgo]

Agree with this, even I can't remember what the range-related functions do off the top of my head 😅.

Doing this would deviate a bit from the decision to stick with PostgREST terminologies, but I think it's worth it for the DX.

[kiwicopple]

Thanks @joshnuss - great suggestions. Moving this here: supabase/postgrest-js#148