🔧 Update config with new pymdown extensions (#712)

* 🔧 Update config with new pymdown extensions

* 📝 Update admonition blocks syntax

* 📝 Update syntax for tabs with new pymdown extensions

docs/tutorial/relationship-attributes/back-populates.md

@@ -58,8 +58,11 @@ As you already know how this works, I won't separate that in a select `statement
 
 </details>
 
-!!! tip
-    When writing your own code, this is probably the style you will use most often, as it's shorter, more convenient, and you still get all the power of autocompletion and inline errors.
+/// tip
+
+When writing your own code, this is probably the style you will use most often, as it's shorter, more convenient, and you still get all the power of autocompletion and inline errors.
+
+///
 
 ## Print the Data
 
@@ -127,8 +130,11 @@ The first important thing is, we *haven't committed* the hero yet, so accessing
 
 But in our code, in this exact point in time, we already said that **Spider-Boy** is no longer part of the **Preventers**. 🔥
 
-!!! tip
-    We could revert that later by not committing the **session**, but that's not what we are interested in here.
+/// tip
+
+We could revert that later by not committing the **session**, but that's not what we are interested in here.
+
+///
 
 Here, at this point in the code, in memory, the code expects **Preventers** to *not include* **Spider-Boy**.
 
@@ -247,10 +253,13 @@ And we can keep the rest of the code the same:
 
 </details>
 
-!!! tip
-    This is the same section where we updated `hero_spider_boy.team` to `None` but we *haven't committed* that change yet.
+/// tip
 
-    The same section that caused a problem before.
+This is the same section where we updated `hero_spider_boy.team` to `None` but we *haven't committed* that change yet.
+
+The same section that caused a problem before.
+
+///
 
 ## Review the Result
 
@@ -336,8 +345,11 @@ So, the string `"heroes"` refers to the attribute `heroes` in the class `Team`.
 
 </details>
 
-!!! tip
-    Each **relationship attribute** points to the other one, in the other model, using `back_populates`.
+/// tip
+
+Each **relationship attribute** points to the other one, in the other model, using `back_populates`.
+
+///
 
 Although it's simple code, it can be confusing to think about 😵, because the same line has concepts related to both models in multiple places:
 

docs/tutorial/relationship-attributes/define-relationships-attributes.md

@@ -123,10 +123,13 @@ And in the `Team` class, the `heroes` attribute is annotated as a list of `Hero`
 
 **SQLModel** (actually SQLAlchemy) is smart enough to know that the relationship is established by the `team_id`, as that's the foreign key that points from the `hero` table to the `team` table, so we don't have to specify that explicitly here.
 
-!!! tip
-    There's a couple of things we'll check again in some of the next chapters, about the `List["Hero"]` and the `back_populates`.
+/// tip
 
-    But for now, let's first see how to use these relationship attributes.
+There's a couple of things we'll check again in some of the next chapters, about the `List["Hero"]` and the `back_populates`.
+
+But for now, let's first see how to use these relationship attributes.
+
+///
 
 ## Next Steps
 

docs/tutorial/relationship-attributes/index.md

@@ -6,9 +6,12 @@ And then we read the data together with `select()` and using `.where()` or `.joi
 
 Now we will see how to use **Relationship Attributes**, an extra feature of **SQLModel** (and SQLAlchemy) to work with the data in the database in way much more familiar way, and closer to normal Python code.
 
-!!! info
-    When I say "**relationship**" I mean the standard dictionary term, of data related to other data.
+/// info
 
-    I'm not using the term "**relation**" that is the technical, academical, SQL term for a single table.
+When I say "**relationship**" I mean the standard dictionary term, of data related to other data.
+
+I'm not using the term "**relation**" that is the technical, academical, SQL term for a single table.
+
+///
 
 And using those **relationship attributes** is where a tool like **SQLModel** really shines. ✨

docs/tutorial/relationship-attributes/read-relationships.md

@@ -77,10 +77,13 @@ So, the highlighted block above, has the same results as the block below:
 
 </details>
 
-!!! tip
-    The automatic data fetching will work as long as the starting object (in this case the `Hero`) is associated with an **open** session.
+/// tip
 
-    For example, here, **inside** a `with` block with a `Session` object.
+The automatic data fetching will work as long as the starting object (in this case the `Hero`) is associated with an **open** session.
+
+For example, here, **inside** a `with` block with a `Session` object.
+
+///
 
 ## Get a List of Relationship Objects
 

docs/tutorial/relationship-attributes/type-annotation-strings.md

@@ -29,5 +29,8 @@ And of course, **SQLModel** can also understand it in the string correctly. ✨
 
 That is actually part of Python, it's the current official solution to handle it.
 
-!!! info
-    There's a lot of work going on in Python itself to make that simpler and more intuitive, and find ways to make it possible to not wrap the class in a string.
+/// info
+
+There's a lot of work going on in Python itself to make that simpler and more intuitive, and find ways to make it possible to not wrap the class in a string.
+
+///