Clarify dotpath usage in `queryables.name`

[mmcfarland]

pgstac ships with 3 queryable definitions, including eo:cloud_cover which may exist on an item content.properties field, but is registered without the properties in its path. It also accepts filter and sort attributes to be sent with or without properties on the path. However, when fetching a queryable record, it looks for an exact match on dotpath:

https://github.com/stac-utils/pgstac/blob/e72a17ca33e552e417a8863bdd4289f9fd4db030/sql/002a_queryables.sql#L51

In the case of eo:cloud_cover, users passing properties.eo:cloud_cover as a sortby value (as used in the examples) won't match a record and the expression will get wrapped in the default to_text, resulting in incorrect sort results.

A couple of options:

• Should pgstac become more strict about using fully qualified paths for input attributes that always include properties. in things like search and sort? It's easy to find stac api spec examples that include or omit properties, but it's not clear if that ambivalence is intentional.
• If not, should we always register queryables with their fully qualified name and ensure they're accessed like how queryable generates the path for its output? https://github.com/stac-utils/pgstac/blob/e72a17ca33e552e417a8863bdd4289f9fd4db030/sql/002a_queryables.sql#L66-L73