fixup! release: remove single quotes in code blocks (Pygments bug)

Folloup from d368202

We learn from pygments/pygments#1598 that the
"console" lexer is actually meant for blocks that present a shell
prompt, a command, and some result:

$ command
result

However we were using this block type as general purpose command
descriptions, which should instead be changed to "shell" type.

For symmetry, those blocks which actually contained prompt + command +
output are renamed from "console" to the equivalent "shell-session".

source/dev/dev_guide.rst

@@ -119,12 +119,11 @@ It is not a trivial task to configure the compiler to use a set of libraries bec
 
 For example, if you want to compile a C program which depends on GLib 2.0, you can run:
 
-.. code-block:: console
+.. code-block:: shell
 
    gcc -o program program.c $(pkg-config --libs --cflags glib-2.0)
 
 
-
 Debian packages
 ---------------
 
@@ -173,7 +172,7 @@ Install required tools
 
 This command will install the basic set of tools that are needed for the next steps:
 
-.. code-block:: console
+.. code-block:: shell
 
    sudo apt-get update && sudo apt-get install --no-install-recommends --yes \
        build-essential \
@@ -189,7 +188,7 @@ Add Kurento repository
 
 Run these commands to add the Kurento repository to your system configuration:
 
-.. code-block:: console
+.. code-block:: shell
 
    # Import the Kurento repository signing key
    sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 5AFA7A83
@@ -212,7 +211,7 @@ Install build dependencies
 
 Run:
 
-.. code-block:: console
+.. code-block:: shell
 
    sudo apt-get update && sudo apt-get install --no-install-recommends --yes \
        kurento-media-server-dev
@@ -224,7 +223,7 @@ Download KMS source code
 
 Run:
 
-.. code-block:: console
+.. code-block:: shell
 
    git clone https://github.com/Kurento/kms-omni-build.git
    cd kms-omni-build
@@ -237,7 +236,7 @@ Run:
 
 *OPTIONAL*: Change to the *master* branch of each submodule, if you will be working with the latest version of the code:
 
-.. code-block:: console
+.. code-block:: shell
 
    REF=master
    git checkout "$REF" || true
@@ -252,7 +251,7 @@ Build and run KMS
 
 Make sure your current directory is already *kms-omni-build*, then run this command:
 
-.. code-block:: console
+.. code-block:: shell
 
    export MAKEFLAGS="-j$(nproc)"
    ./bin/kms-build-run.sh
@@ -270,7 +269,7 @@ To leave the system in a clean state, remove all KMS packages and related develo
 
 Run:
 
-.. code-block:: console
+.. code-block:: shell
 
     PACKAGES=(
         # KMS main components + extra modules
@@ -310,7 +309,7 @@ Whenever working with KMS source code itself, of during any analysis of crash in
 
 After having :doc:`installed Kurento </user/installation>`, first thing to do is to enable the Ubuntu's official **Debug Symbol Packages** repository:
 
-.. code-block:: console
+.. code-block:: shell
 
    # Import the Ubuntu debug repository signing key
    sudo apt-key adv \
@@ -329,7 +328,7 @@ After having :doc:`installed Kurento </user/installation>`, first thing to do is
 
 Now, install all debug symbols that are relevant to KMS:
 
-.. code-block:: console
+.. code-block:: shell
 
    sudo apt-get update && sudo apt-get install --no-install-recommends --yes \
        kurento-dbg
@@ -341,9 +340,9 @@ Why are debug symbols useful?
 
 Let's see a couple examples that show the difference between the same stack trace, as generated *before* installing the debug symbols, and *after* installing them. **Don't report a stack trace that looks like the first one in this example**:
 
-.. code-block:: text
+**NOT USEFUL**: WITHOUT debug symbols:
 
-   # ==== NOT USEFUL: WITHOUT debug symbols ====
+.. code-block:: shell-session
 
    $ cat /var/log/kurento-media-server/errors.log
    Segmentation fault (thread 139667051341568, pid 14132)
@@ -357,9 +356,9 @@ Let's see a couple examples that show the difference between the same stack trac
    [g_hook_list_marshal]
    /lib/x86_64-linux-gnu/libglib-2.0.so.0:0x3A904
 
-.. code-block:: text
+**USEFUL** WITH debug symbols:
 
-   # ==== USEFUL: WITH debug symbols ====
+.. code-block:: shell-session
 
    $ cat /var/log/kurento-media-server/errors.log
    Segmentation fault (thread 140672899761920, pid 15217)
@@ -401,7 +400,7 @@ From sources
 
    For this step, the easiest method is to use our launch script, *kms-build-run.sh*. It builds all sources, configures the environment, and starts up the debugger:
 
-   .. code-block:: console
+   .. code-block:: shell
 
       ./bin/kms-build-run.sh --gdb
       # [... wait for build ...]
@@ -424,21 +423,21 @@ You don't *have* to build KMS from sources in order to run it with the GDB debug
 
    This helps capturing assertions from 3rd-party libraries used by Kurento, such as *GLib* and *GStreamer*:
 
-   .. code-block:: console
+   .. code-block:: shell
 
       export G_DEBUG=fatal-warnings
 
 4. Load your service settings.
 
    You possibly did some changes in the KMS service settings file, ``/etc/default/kurento-media-server``. This file contains shell code that can be sourced directly into your current session:
 
-   .. code-block:: console
+   .. code-block:: shell
 
       source /etc/default/kurento-media-server
 
 5. Ensure KMS is not already running as a service, and run it with GDB.
 
-   .. code-block:: console
+   .. code-block:: shell
 
       sudo service kurento-media-server stop
 
@@ -455,7 +454,7 @@ GDB commands
 
 Once you see the ``(gdb)`` command prompt, you're already running a `GDB session <https://www.cprogramming.com/gdb.html>`__, and you can start issuing debug commands. Here, the most useful ones are *backtrace* and *info* variants (`Examining the Stack <https://sourceware.org/gdb/current/onlinedocs/gdb/Stack.html>`__). When you want to finish, stop execution with *Ctrl+C*, then type the *quit* command:
 
-.. code-block:: console
+.. code-block:: shell
 
    # Actually start running the KMS process
    (gdb) run
@@ -529,7 +528,7 @@ You can also use *kurento-buildpackage* locally, to build test packages while wo
 
 For example, say you want to build the current *kms-core* development branch against Kurento 6.12.0. Run these commands:
 
-.. code-block:: console
+.. code-block:: shell
 
    git clone https://github.com/Kurento/adm-scripts.git
    git clone https://github.com/Kurento/kms-core.git
@@ -551,7 +550,7 @@ To use the `kurento-buildpackage Docker image <https://hub.docker.com/r/kurento/
 
 For example, say you want to build the current *kms-core* development branch against Kurento 6.12.0, for *Ubuntu 16.04 (Xenial)* systems. Run these commands:
 
-.. code-block:: console
+.. code-block:: shell
 
    git clone https://github.com/Kurento/kms-core.git
    cd kms-core/
@@ -574,7 +573,7 @@ KMS uses the Check unit testing framework for C (https://libcheck.github.io/chec
 
    The complete command would look like this:
 
-   .. code-block:: console
+   .. code-block:: shell
 
       export GST_DEBUG_NO_COLOR=1
       export GST_DEBUG="3,check:5"
@@ -588,13 +587,13 @@ The log output of the whole test suite will get saved into the file *./Testing/T
 
 To build and run one specific test, use ``make {TestName}.check``. For example:
 
-.. code-block:: console
+.. code-block:: shell
 
    make test_agnosticbin.check
 
 If you want to analyze memory usage with Valgrind, use ``make {TestName}.valgrind``. For example:
 
-.. code-block:: console
+.. code-block:: shell
 
    make test_agnosticbin.valgrind
 
@@ -641,7 +640,7 @@ What to do when you are developing a new feature that spans across KMS and the p
 
 2. Generate client SDK dependencies:
 
-   .. code-block:: console
+   .. code-block:: shell
 
       cd <module>  # E.g. kms-filters
       rm -rf build
@@ -652,7 +651,7 @@ What to do when you are developing a new feature that spans across KMS and the p
 
 3. Generate client SDK:
 
-   .. code-block:: console
+   .. code-block:: shell
 
       cd kurento-java
       mvn clean install

source/dev/hardening.rst

@@ -31,7 +31,7 @@ Hardening validation
 
 Debian-based distributions provide the *hardening-check* tool (package *hardening-includes*), which can be used to check if a binary file (either an executable or a shared library) was properly hardened:
 
-.. code-block:: console
+.. code-block:: shell-session
 
    $ hardening-check /usr/sbin/sshd
    /usr/sbin/sshd: