doc: porting: Set proper languages for syntax highlighting

Make sure devicetree, kconfig, etc. code snippets all have proper
pygments language set.

Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>

doc/hardware/porting/arch.rst

@@ -535,7 +535,7 @@ The region specified by	``thread.stack_info.start`` and
 the initial stack pointer from the very end of the stack object, taking into
 account storage for TLS and ASLR random offsets.
 
-::
+.. code-block:: none
 
 	+---------------------+ <- thread.stack_obj
 	| Reserved Memory     | } K_(THREAD|KERNEL)_STACK_RESERVED
@@ -624,7 +624,7 @@ simply leave an non-present virtual page below every stack when it is mapped
 into the address space. The stack object will still need to be properly aligned
 and sized to page granularity.
 
-::
+.. code-block:: none
 
    +-----------------------------+ <- thread.stack_obj
    | Guard reserved memory       | } K_KERNEL_STACK_RESERVED
@@ -683,7 +683,7 @@ On systems without power-of-two region requirements, the reserved memory area
 for threads stacks defined by :c:macro:`K_THREAD_STACK_RESERVED` may be used to
 contain the privilege mode stack. The layout could be something like:
 
-::
+.. code-block:: none
 
    +------------------------------+ <- thread.stack_obj
    | Other platform data          |
@@ -742,7 +742,7 @@ of the privilege stacks can be looked up quickly at runtime based on the
 thread stack address using :c:func:`z_priv_stack_find()`. These stacks are
 laid out the same way as other kernel-only stacks.
 
-::
+.. code-block:: none
 
    +-----------------------------+ <- z_priv_stack_find(thread.stack_obj)
    | Reserved memory             | } K_KERNEL_STACK_RESERVED

doc/hardware/porting/board_porting.rst

@@ -327,7 +327,7 @@ named ``plank``:
   This should at least contain a definition for a ``BOARD_PLANK`` option,
   which looks something like this:
 
-  .. code-block:: none
+  .. code-block:: kconfig
 
      config BOARD_PLANK
      	bool "Plank board"
@@ -340,7 +340,7 @@ named ``plank``:
   The entire file should be inside an ``if BOARD_PLANK`` / ``endif`` pair of
   lines, like this:
 
-  .. code-block:: none
+  .. code-block:: kconfig
 
      if BOARD_PLANK
 
@@ -369,10 +369,10 @@ named ``plank``:
   your system clock, console, etc. The results are architecture-specific, but
   typically look something like this:
 
-  .. code-block:: none
+  .. code-block:: cfg
 
-     CONFIG_SOC_${VENDOR_XYZ3000}=y                      /* select your SoC */
+     CONFIG_SOC_${VENDOR_XYZ3000}=y                # select your SoC
-     CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC=120000000   /* set up your clock, etc */
+     CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC=120000000  # set up your clock, etc
      CONFIG_SERIAL=y
 
 :file:`plank_x_y_z.conf`

doc/hardware/porting/shields.rst

@@ -101,7 +101,7 @@ CMake command
 
 Alternatively, it could be set by default in a project's CMakeLists.txt:
 
-.. code-block:: none
+.. code-block:: cmake
 
 	set(SHIELD x_nucleo_iks01a1)
 
@@ -153,7 +153,7 @@ node`_ that looks like the following into the board devicetree file:
 .. _nexus node:
     https://github.com/devicetree-org/devicetree-specification/blob/4b1dac80eaca45b4babf5299452a951008a5d864/source/devicetree-basics.rst#nexus-nodes-and-specifier-mapping
 
-.. code-block:: none
+.. code-block:: devicetree
 
     arduino_header: connector {
             compatible = "arduino-header-r3";
@@ -193,7 +193,7 @@ bits of the flags correspond to features that can be configured in
 devicetree.  In some cases it's necessary to use a non-zero flag value
 to tell the driver how a particular pin behaves, as with:
 
-.. code-block:: none
+.. code-block:: devicetree
 
     drdy-gpios = <&arduino_header 11 GPIO_ACTIVE_LOW>;