Correct code-block lexers

Changing `bash` lexer to `console` because it is appropriate most of
the time. Then after a manual review, some lexer have been changed.

I used `text` each time I was unsure, and for prompt outputs.

The page `/developer/building/qubes-iso-building.rst` still need to be
reviewed (look for lines starting with `$ #`).

I'm not sure about the Windows pages, should we use
[doscon](https://pygments.org/docs/lexers/#pygments.lexers.shell.MSDOSSessionLexer)
or `powershell`?

Is there an appropriate lexer for `guid.conf` content?

**Statistics - Before**
    870 bash
      9 python
      9 c
      2 yaml

**Statistics - After**
    684 console
    111 text
     44 bash
     16 yaml
      9 systemd
      9 c
      8 python
      4 ini
      4 doscon
      2 markdown
      2 desktop
      1 xorg.conf
      1 xml+jinja
      1 xml
      1 kconfig
      1 html

This suggests that the default lexer should be `console`.

developer/system/networking.rst

@@ -17,8 +17,8 @@ Routing tables examples
 
 VM routing table is simple:
 
-.. list-table::  
-      :widths: 4 4 4 4 4 4 4 4 
+.. list-table::
+      :widths: 4 4 4 4 4 4 4 4
       :align: center
       :header-rows: 1
 
@@ -38,12 +38,12 @@ VM routing table is simple:
         - 0
         - 0
         - eth0
-      
+
 
 Network driver domain routing table is a bit longer:
 
-.. list-table::  
-      :widths: 1 1 1 1 1 1 1 1 
+.. list-table::
+      :widths: 1 1 1 1 1 1 1 1
       :align: center
       :header-rows: 1
 
@@ -111,7 +111,7 @@ Network driver domain routing table is a bit longer:
         - 0
         - 0
         - eth0
-      
+
 
 IPv6
 ----
@@ -119,7 +119,7 @@ IPv6
 
 Starting with Qubes 4.0, there is opt-in support for IPv6 forwarding. Similar to the IPv4, traffic is routed and NAT is applied at each network gateway. This way we avoid reconfiguring every connected qube whenever uplink connection is changed, and even telling the qube what that uplink is - which may be complex when VPN or other tunneling services are employed. The feature can be enabled on any network-providing qube, and will be propagated down the network tree, so every qube connected to it will also have IPv6 enabled. To enable the ``ipv6`` feature use ``qvm-features`` tool and set the value to ``1``. For example to enable it on ``sys-net``, execute in dom0:
 
-.. code:: bash
+.. code:: console
 
       qvm-features sys-net ipv6 1
 
@@ -127,7 +127,7 @@ Starting with Qubes 4.0, there is opt-in support for IPv6 forwarding. Similar to
 
 It is also possible to explicitly disable IPv6 support for some qubes, even if it is connected to IPv6-providing one. This can be done by setting ``ipv6`` feature to empty value:
 
-.. code:: bash
+.. code:: console
 
       qvm-features ipv4-only-qube ipv6 ''
 

developer/system/template-manager.rst

@@ -247,7 +247,7 @@ Input
 
 Both calls accept the following format from standard input:
 
-.. code:: bash
+.. code:: text
 
       arg1
       arg2

developer/system/vm-sudo.rst

@@ -9,11 +9,11 @@ This page sets out the configuration changes made, with (not necessary complete)
 
 1. sudo (``/etc/sudoers.d/qubes``):
 
-   .. code:: bash
+   .. code:: text
 
          Defaults !requiretty
          %qubes ALL=(ALL) ROLE=unconfined_r TYPE=unconfined_t NOPASSWD: ALL
-         
+
          (...)
 
 
@@ -26,7 +26,7 @@ This page sets out the configuration changes made, with (not necessary complete)
 
 2. PolicyKit (``/etc/polkit-1/rules.d/00-qubes-allow-all.rules``):
 
-   .. code:: bash
+   .. code:: text
 
          //allow any action, detailed reasoning in sudoers.d/qubes
          polkit.addRule(function(action,subject) { if (subject.isInGroup("qubes")) return polkit.Result.YES; });