chore: various markdown warnings resolved (#30657)

Co-authored-by: Evan Rusackas <evan@preset.io>

docs/docs/configuration/sql-templating.mdx

@@ -77,6 +77,7 @@ In the UI you can assign a set of parameters as JSON
   "my_table": "foo"
 }
 ```
+
 The parameters become available in your SQL (example: `SELECT * FROM {{ my_table }}` ) by using Jinja templating syntax.
 SQL Lab template parameters are stored with the dataset as `TEMPLATE PARAMETERS`.
 
@@ -103,7 +104,6 @@ GROUP BY action
 
 Note ``_filters`` is not stored with the dataset. It's only used within the SQL Lab UI.
 
-
 Besides default Jinja templating, SQL lab also supports self-defined template processor by setting
 the `CUSTOM_TEMPLATE_PROCESSORS` in your superset configuration. The values in this dictionary
 overwrite the default Jinja template processors of the specified database engine. The example below
@@ -186,7 +186,7 @@ cache hit in the future and Superset can retrieve cached data.
 You can disable the inclusion of the `username` value in the calculation of the
 cache key by adding the following parameter to your Jinja code:
 
-```
+```python
 {{ current_username(add_to_cache_keys=False) }}
 ```
 
@@ -201,7 +201,7 @@ cache hit in the future and Superset can retrieve cached data.
 You can disable the inclusion of the account `id` value in the calculation of the
 cache key by adding the following parameter to your Jinja code:
 
-```
+```python
 {{ current_user_id(add_to_cache_keys=False) }}
 ```
 
@@ -216,7 +216,7 @@ cache hit in the future and Superset can retrieve cached data.
 You can disable the inclusion of the email value in the calculation of the
 cache key by adding the following parameter to your Jinja code:
 
-```
+```python
 {{ current_user_email(add_to_cache_keys=False) }}
 ```
 
@@ -301,7 +301,7 @@ This is useful if:
 
 Here's a concrete example:
 
-```
+```sql
  WITH RECURSIVE
     superiors(employee_id, manager_id, full_name, level, lineage) AS (
     SELECT
@@ -357,6 +357,7 @@ considerably improve performance, as many databases and query engines are able t
 if the temporal filter is placed on the inner query, as opposed to the outer query.
 
 The macro takes the following parameters:
+
 - `column`: Name of the temporal column. Leave undefined to reference the time range from a Dashboard Native Time Range
   filter (when present).
 - `default`: The default value to fall back to if the time filter is not present, or has the value `No filter`
@@ -370,6 +371,7 @@ The macro takes the following parameters:
   filter should only apply to the inner query.
 
 The return type has the following properties:
+
 - `from_expr`: the start of the time filter (if any)
 - `to_expr`: the end of the time filter (if any)
 - `time_range`: The applied time range
@@ -410,6 +412,7 @@ LIMIT 1000;
 
 When using the `default` parameter, the templated query can be simplified, as the endpoints will always be defined
 (to use a fixed time range, you can also use something like `default="2024-08-27 : 2024-09-03"`)
+
 ```
 {% set time_filter = get_time_filter("dttm", default="Last week", remove_filter=True) %}
 SELECT
@@ -429,19 +432,19 @@ To use the macro, first you need to find the ID of the dataset. This can be done
 
 Once you have the ID you can query it as if it were a table:
 
-```
+```sql
 SELECT * FROM {{ dataset(42) }} LIMIT 10
 ```
 
 If you want to select the metric definitions as well, in addition to the columns, you need to pass an additional keyword argument:
 
-```
+```sql
 SELECT * FROM {{ dataset(42, include_metrics=True) }} LIMIT 10
 ```
 
 Since metrics are aggregations, the resulting SQL expression will be grouped by all non-metric columns. You can specify a subset of columns to group by instead:
 
-```
+```sql
 SELECT * FROM {{ dataset(42, include_metrics=True, columns=["ds", "category"]) }} LIMIT 10
 ```