remove duplicate content for certain SQL sections under Explore and Analyze (#3117)

Linked to #2563
This PR removes the following under Explore and Analyze -> SQL and
creates redirects to the corresponding reference content. Also updates
all referred links to these files with the reference content links.

- SQL Language
- Functions and Operators
- Reserved keywords
- SQL Limitations

---------

Co-authored-by: Vlada Chirmicci <[email protected]>
Co-authored-by: Marci W <[email protected]>

Author: 3 people

explore-analyze/query-filter/languages/sql-cli.md

@@ -28,7 +28,7 @@ If security is enabled on your cluster, you can pass the username and password i
 $ ./bin/elasticsearch-sql-cli https://sql_user:[email protected]:9200
 ```
 
-Once the CLI is running you can use any [query](sql-spec.md) that Elasticsearch supports:
+Once the CLI is running you can use any [query](elasticsearch://reference/query-languages/sql/sql-spec.md) that Elasticsearch supports:
 
 ```sql
 sql> SELECT * FROM library WHERE page_count > 500 ORDER BY page_count DESC;

explore-analyze/query-filter/languages/sql-commands.md

@@ -29,7 +29,7 @@ So let’s start from the bottom; these roughly are:
 
 | SQL | {{es}} | Description |
 | --- | --- | --- |
-| `column` | `field` | In both cases, at the lowest level, data is stored in *named* entries, of a variety of [data types](sql-data-types.md), containing *one* value. SQL calls such an entry a *column* while {{es}} a *field*.Notice that in {{es}} a field can contain *multiple* values of the same type (essentially a list) while in SQL, a *column* can contain *exactly* one value of said type.Elasticsearch SQL will do its best to preserve the SQL semantic and, depending on the query, reject those that return fields with more than one value. |
+| `column` | `field` | In both cases, at the lowest level, data is stored in *named* entries, of a variety of [data types](elasticsearch://reference/query-languages/sql/sql-data-types.md), containing *one* value. SQL calls such an entry a *column* while {{es}} a *field*. Notice that in {{es}} a field can contain *multiple* values of the same type (essentially a list) while in SQL, a *column* can contain *exactly* one value of said type. Elasticsearch SQL will do its best to preserve the SQL semantic and, depending on the query, reject those that return fields with more than one value. |
 | `row` | `document` | `Column`s and `field`s do *not* exist by themselves; they are part of a `row` or a `document`. The two have slightly different semantics: a `row` tends to be *strict* (and have more enforcements) while a `document` tends to be a bit more flexible or loose (while still having a structure). |
 | `table` | `index` | The target against which queries, whether in SQL or {{es}} get executed against. |
 | `schema` | *implicit* | In RDBMS, `schema` is mainly a namespace of tables and typically used as a security boundary. {{es}} does not provide an equivalent concept for it. However when security is enabled, {{es}} automatically applies the security enforcement so that a role sees only the data it is allowed to (in SQL jargon, its *schema*). |