Rewrite code blocks from markdown style to asciidoc style

Since asciidoc parser, which is used for generating localized
sites(ja.quarkus.io, cn.quarkus.io, and es.quarkus.io) cannot parse
Markdown style code block, some localized docs are broken:
https://ja.quarkus.io/guides/building-native-image
https://cn.quarkus.io/guides/building-native-image

It is not easy to fix the parser, this commit rewrites code blocks
from markdown style to asciidoc style

docs/src/main/asciidoc/building-native-image.adoc

@@ -293,12 +293,13 @@ You can override the profile the executable is *built* with and *runs* with usin
 `./mvnw clean verify -Pnative -Dquarkus-profile=test`. This might come handy if there are test specific resources to be processed,
 such as importing test data into the database.
 
-```
+[source,properties]
+----
 quarkus.native.resources.includes=version.txt
 %test.quarkus.native.resources.includes=version.txt,import-dev.sql
 %test.quarkus.hibernate-orm.database.generation=drop-and-create
 %test.quarkus.hibernate-orm.sql-load-script=import-dev.sql
-```
+----
 
 With the aforementioned example in your `application.properties`, your Hibernate ORM managed database will be populated with test
 data both during the JVM mode test run and during the native mode test run. The production

docs/src/main/asciidoc/deploying-to-openshift.adoc

@@ -136,9 +136,12 @@ The input of the build is the jar that has been built locally and the output of
 [NOTE]
 ====
 During the build you may find the `Caused by: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed` exception due to self-signed certificate. To solve this, just add the following line to your `application.properties`:
-```properties
+
+[source,properties]
+----
 quarkus.kubernetes-client.trust-certs=true
-```
+----
+
 For more information, see link:https://quarkus.io/guides/deploying-to-kubernetes#client-connection-configuration[deploying to kubernetes].
 ====
 

docs/src/main/asciidoc/security-jwt-build.adoc

@@ -119,9 +119,10 @@ String jwt = Jwt.upn("Alice").jws().algorithm(SignatureAlgorithm.PS256).sign();
 
 Alternatively you can use a `smallrye.jwt.new-token.signature-algorithm` property:
 
-```properties
+[source,properties]
+----
 smallrye.jwt.new-token.signature-algorithm=PS256
-```
+----
 
 and write a simpler API sequence:
 
@@ -181,10 +182,11 @@ String jwt = Jwt.subject("Bob").jwe()
 
 Alternatively you can use `smallrye.jwt.new-token.key-encryption-algorithm` and `smallrye.jwt.new-token.content-encryption-algorithm` properties to customize the key and content encryption algorithms:
 
-```properties
+[source,properties]
+----
 smallrye.jwt.new-token.key-encryption-algorithm=RSA-OAEP-256
 smallrye.jwt.new-token.content-encryption-algorithm=A256CBC-HS512
-```
+----
 
 and write a simpler API sequence:
 

docs/src/main/asciidoc/security-jwt.adoc

@@ -660,7 +660,8 @@ Use `mp.jwt.verify.publickey.algorithm` to customize the verification algorithm
 
 If you need to verify the token signature using the symmetric secret key then either a `JSON Web Key` (JWK) or `JSON Web Key Set` (JWK Set) format must be used to represent this secret key, for example:
 
-```json
+[source,json]
+----
 {
  "keys": [
    {
@@ -670,7 +671,7 @@ If you need to verify the token signature using the symmetric secret key then ei
    }
  ]
 }
-```
+----
 
 This secret key JWK will also need to be referred to with `smallrye.jwt.verify.key.location`.
 `smallrye.jwt.verify.algorithm` should be set to `HS256`/`HS384`/`HS512`.

docs/src/main/asciidoc/writing-extensions.adoc

@@ -3175,10 +3175,11 @@ Before publishing your extension to the xref:tooling.adoc[Quarkus tooling], make
 
 Then you must create a pull request adding a `your-extension.yaml` file in the `extensions/` directory in the link:https://github.com/quarkusio/quarkus-extension-catalog[Quarkus Extension Catalog]. The YAML must have the following structure:
 
-```yaml
+[source,yaml]
+----
 group-id: <YOUR_EXTENSION_RUNTIME_GROUP_ID>
 artifact-id: <YOUR_EXTENSION_RUNTIME_ARTIFACT_ID>
-```
+----
 
 That's all. Once the pull request is merged, a scheduled job will check Maven Central for new versions and update the xref:extension-registry-user.adoc[Quarkus Extension Registry].