Also flag concurrent index creation

Creating indices concurrently (provided that index creation *completes*)
is generally a much safer way to build an index (since it allows reads
*and* writes to the table during index creation).

However, due to the inherent tradeoffs of concurrent index creation, the
operation will almost always take *longer* than a traditional (blocking)
index creation. It's actually much *more* important to lint against
concurrent index creation when an exclusive lock is open & held.

Test is from a comment by @David-Wobrock (I corrected syntax, though):
https://github.com/3YOURMIND/django-migration-linter/pull/251#discussion_r1249298197

django_migration_linter/sql_analyser/postgresql.py

@@ -31,17 +31,17 @@ def has_create_index_in_transaction(sql_statements: list[str], **kwargs) -> bool
         #     https://www.postgresql.org/docs/current/sql-altertable.html
         # (Most common example is `ALTER TABLE... ADD COLUMN`, then later `CREATE INDEX`)
         if sql.startswith("ALTER TABLE"):
-            return has_create_index(sql_statements[i + 1 :])
+            return has_create_index(sql_statements[i + 1 :], ignore_concurrently=False)
     return False
 
 
-def has_create_index(sql_statements: list[str], **kwargs) -> bool:
+def has_create_index(sql_statements: list[str], ignore_concurrently: bool = True, **kwargs) -> bool:
     regex_result = None
     for sql in sql_statements:
         regex_result = re.search(r"CREATE (UNIQUE )?INDEX.*ON (.*) \(", sql)
-        if re.search("INDEX CONCURRENTLY", sql):
+        if ignore_concurrently and re.search("INDEX CONCURRENTLY", sql):
             regex_result = None
-        elif regex_result:
+        if regex_result:
             break
     if not regex_result:
         return False