doc: major restructuring of the doc folder

Reorganizing the doc/nrf folder to make it easier to
locate specific RST files whenever they need modification.

The folder now has a clear structure of subfolders rather than
having most of the files on the main level.

Scope of work:

- Moved files for different user guides from the main level
  to respective subfolders (protocols, working with, app_dev).
  If a user guide has chapters made of more than one RST file,
  additional subfolders are created.
- This change means we no longer need all the vague prefixes
  in the file names - 'ug', 'gs' etc.
  File names have been shortened and simplified.
- Renamed the parent file of these user guides to index.rst
  for easier identification.
- Created an 'images' folder for every such folder.
  Images now reside next to the RST files in which they are
  used rather than in a common folder.
- Added a new main section for Ecosystem integration guides,
  with its respective folder.
- Edited many RST files to fix broken paths to images after
  they have been moved.
- Fixed broken includes leading to files that have been
  relocated.
- Removed all Visio source files (.vsdx) for the svg images.
  These binary files will now be stored outside of Github.

Signed-off-by: Bartosz Gentkowski <bartosz.gentkowski@nordicsemi.no>

applications/machine_learning/README.rst

@@ -193,7 +193,7 @@ Other build types are covered by dedicated files with the build type added as a
 For example, the ``release`` build type file name is :file:`prj_release.conf`.
 If a board has other configuration files, for example associated with partition layout or child image configuration, these follow the same pattern.
 
-.. include:: /gs_modifying.rst
+.. include:: /getting_started/modifying.rst
    :start-after: build_types_overview_start
    :end-before: build_types_overview_end
 
@@ -367,14 +367,14 @@ Before you start testing the application, you can select one of the :ref:`nrf_ma
 Selecting a build type in |VSC|
 -------------------------------
 
-.. include:: /gs_modifying.rst
+.. include:: /getting_started/modifying.rst
    :start-after: build_types_selection_vsc_start
    :end-before: build_types_selection_vsc_end
 
 Selecting a build type from command line
 ----------------------------------------
 
-.. include:: /gs_modifying.rst
+.. include:: /getting_started/modifying.rst
    :start-after: build_types_selection_cmd_start
    :end-before: build_types_selection_cmd_end
 
@@ -493,7 +493,7 @@ To start forwarding data to Edge Impulse studio:
    a. Select the :guilabel:`Data acquisition` tab.
    #. In the **Record new data** panel, set the desired values and click :guilabel:`Start sampling`.
 
-      .. figure:: ../../doc/nrf/images/ei_data_acquisition.png
+      .. figure:: /images/ei_data_acquisition.png
          :scale: 50%
          :alt: Sampling under Data acquisition in Edge Impulse studio
 
@@ -502,7 +502,7 @@ To start forwarding data to Edge Impulse studio:
    #. Observe the received sample data on the raw data graph under the panel.
       The observed signal depends on the acceleration readouts.
 
-      .. figure:: ../../doc/nrf/images/ei_start_sampling.png
+      .. figure:: /images/ei_start_sampling.png
          :scale: 50%
          :alt: Sampling example
 

applications/matter_weather_station/README.rst

@@ -82,7 +82,7 @@ Other build types are covered by dedicated files with the build type added as a
 For example, the ``release`` build type file name is :file:`prj_release.conf`.
 If a board has other configuration files, for example associated with partition layout or child image configuration, these follow the same pattern.
 
-.. include:: /gs_modifying.rst
+.. include:: /getting_started/modifying.rst
    :start-after: build_types_overview_start
    :end-before: build_types_overview_end
 
@@ -153,14 +153,14 @@ Before you start testing the application, you can select one of the :ref:`matter
 Selecting a build type in |VSC|
 -------------------------------
 
-.. include:: /gs_modifying.rst
+.. include:: /getting_started/modifying.rst
    :start-after: build_types_selection_vsc_start
    :end-before: build_types_selection_vsc_end
 
 Selecting a build type from command line
 ----------------------------------------
 
-.. include:: /gs_modifying.rst
+.. include:: /getting_started/modifying.rst
    :start-after: build_types_selection_cmd_start
    :end-before: For example, you can replace the
 
@@ -283,7 +283,7 @@ Alternatively, depending on your build type, you can also use one of the followi
        - Manual pairing code
      * - Scan the following QR code with the app for your ecosystem:
 
-         .. figure:: ../../doc/nrf/images/matter_qr_code_weather_station_default.png
+         .. figure:: /images/matter_qr_code_weather_station_default.png
             :width: 200px
             :alt: QR code for commissioning the weather station device (debug build type)
 
@@ -300,7 +300,7 @@ Alternatively, depending on your build type, you can also use one of the followi
        - Manual pairing code
      * - Scan the following QR code with the app for your ecosystem:
 
-         .. figure:: ../../doc/nrf/images/matter_qr_code_weather_station_factory_data.png
+         .. figure:: /images/matter_qr_code_weather_station_factory_data.png
             :width: 200px
             :alt: QR code for commissioning the weather station device (factory data build type)
 

applications/nrf5340_audio/README.rst

@@ -22,7 +22,7 @@ Feature support matrix
    .. note::
       Features not listed are not supported.
 
-   .. include:: ../../doc/nrf/software_maturity.rst
+   .. include:: /software_maturity.rst
       :start-after: software_maturity_application_nrf5340audio_table:
       :end-before: software_maturity_protocol
 

applications/nrf_desktop/README.rst

@@ -384,7 +384,7 @@ Other build types are covered by dedicated files with the build type added as a
 For example, the ``release`` build type file name is :file:`prj_release.conf`.
 If a board has other configuration files, for example associated with partition layout or child image configuration, these follow the same pattern.
 
-.. include:: /gs_modifying.rst
+.. include:: /getting_started/modifying.rst
    :start-after: build_types_overview_start
    :end-before: build_types_overview_end
 
@@ -849,14 +849,14 @@ Before you start testing the application, you can select one of the :ref:`nrf_de
 Selecting a build type in |VSC|
 -------------------------------
 
-.. include:: /gs_modifying.rst
+.. include:: /getting_started/modifying.rst
    :start-after: build_types_selection_vsc_start
    :end-before: build_types_selection_vsc_end
 
 Selecting a build type from command line
 ----------------------------------------
 
-.. include:: /gs_modifying.rst
+.. include:: /getting_started/modifying.rst
    :start-after: build_types_selection_cmd_start
    :end-before: build_types_selection_cmd_end
 

applications/zigbee_weather_station/README.rst

@@ -56,7 +56,7 @@ Other build types are covered by dedicated files with the build type added as a
 For example, the ``release`` build type file name is :file:`prj_release.conf`.
 If a board has other configuration files, for example associated with partition layout or child image configuration, these follow the same pattern.
 
-.. include:: /gs_modifying.rst
+.. include:: /getting_started/modifying.rst
    :start-after: build_types_overview_start
    :end-before: build_types_overview_end
 
@@ -185,14 +185,14 @@ Before you start testing the application, you can select one of the :ref:`zigbee
 Selecting a build type in |VSC|
 -------------------------------
 
-.. include:: /gs_modifying.rst
+.. include:: /getting_started/modifying.rst
    :start-after: build_types_selection_vsc_start
    :end-before: build_types_selection_vsc_end
 
 Selecting a build type from command line
 ----------------------------------------
 
-.. include:: /gs_modifying.rst
+.. include:: /getting_started/modifying.rst
    :start-after: build_types_selection_cmd_start
    :end-before: For example, you can replace the
 

doc/nrf/app_dev.rst

@@ -0,0 +1,22 @@
+.. _ug_app_dev:
+
+Application development
+#######################
+
+The following user guides introduce important concepts to consider when developing a new application based on the |NCS|:
+
+.. toctree::
+   :maxdepth: 1
+   :caption: Subpages:
+
+   app_dev/board_support/index
+   app_dev/pin_control/index
+   app_dev/build_and_config_system/index
+   app_dev/optimizing/index
+   app_dev/bootloaders_and_dfu/index
+   app_dev/logging/index
+   app_dev/multi_image/index
+   app_dev/testing_unity_cmock/index
+   app_dev/tfm/index
+   app_dev/working_with_fem/index
+   app_dev/wifi_coex/index

doc/nrf/ug_fw_update.rst → doc/nrf/app_dev/bootloaders_and_dfu/fw_update.rst

@@ -270,7 +270,7 @@ With the |NCS|, you must choose the method for versioning an image for use in fi
 Using |NSIB|
 ============
 
-.. include:: ../../samples/bootloader/README.rst
+.. include:: ../../../../samples/bootloader/README.rst
    :start-after: bootloader_monotonic_counter_start
    :end-before: bootloader_monotonic_counter_end
 

doc/nrf/app_bootloaders.rst → doc/nrf/app_dev/bootloaders_and_dfu/index.rst

@@ -67,9 +67,9 @@ See the following user guides to learn more:
    :maxdepth: 2
    :caption: Subpages:
 
-   ug_bootloader
-   ug_bootloader_adding
-   ug_bootloader_testing
-   ug_bootloader_external_flash
-   ug_bootloader_config
-   ug_fw_update
+   bootloader
+   bootloader_adding
+   bootloader_testing
+   bootloader_external_flash
+   bootloader_config
+   fw_update

doc/nrf/ug_multi_image.rst → doc/nrf/app_dev/multi_image/index.rst

@@ -18,7 +18,7 @@ The most common use cases for builds composed of multiple images are application
 What image files are
 ********************
 
-.. include:: app_build_system.rst
+.. include:: ../build_and_config_system/index.rst
    :start-after: output_build_files_info_start
    :end-before: output_build_files_info_end
 
@@ -30,7 +30,7 @@ Using multiple images has the following advantages:
   This is useful for bootloader images, which can require their own copy of a library that the application uses, but in a different version or configuration.
 * In multi-core builds, the build configuration of a child image in a separate core can be made known to the parent image.
 
-.. include:: app_build_system.rst
+.. include:: ../build_and_config_system/index.rst
    :start-after: output_build_files_table_start
    :end-before: output_build_files_table_end
 
@@ -152,7 +152,7 @@ In some scenarios, this is not possible without modifying the |NCS| build code,
 To avoid this issue, use the *Modules* mechanism provided by the Zephyr build system.
 The following example shows how to add the required module from a top-level sample :file:`CMakeLists.txt`.
 
-.. literalinclude:: ../../samples/nrf5340/multicore/CMakeLists.txt
+.. literalinclude:: ../../../../samples/nrf5340/multicore/CMakeLists.txt
     :language: cmake
     :start-at: cmake_minimum_required
     :end-at: target_sources
@@ -161,12 +161,12 @@ A :file:`zephyr/module.yml` file is needed at the base of the added module.
 The following example specifies only the path to the :file:`CMakeLists.txt` of the new module.
 See :ref:`modules` for more details.
 
-.. literalinclude:: ../../samples/nrf5340/multicore/zephyr/module.yml
+.. literalinclude:: ../../../../samples/nrf5340/multicore/zephyr/module.yml
     :language: yaml
 
 The :file:`CMakeLists.txt` located in the directory pointed to by :file:`zephyr/module.yml` will be invoked when ``add_child_image`` can be invoked.
 
-.. literalinclude:: ../../samples/nrf5340/multicore/aci/CMakeLists.txt
+.. literalinclude:: ../../../../samples/nrf5340/multicore/aci/CMakeLists.txt
     :language: cmake
     :start-at: add_child_image
     :end-before: endif()
@@ -228,7 +228,7 @@ With west, you can pass these configuration variables into CMake by using the ``
 You can make a project pass Kconfig configuration files, fragments, and devicetree overlays to child images by placing them in the :file:`child_image` folder in the application source directory.
 The listing below describes how to leverage this functionality, where ``ACI_NAME`` is the name of the child image to which the configuration will be applied.
 
-.. literalinclude:: ../../cmake/multi_image.cmake
+.. literalinclude:: ../../../../cmake/multi_image.cmake
     :language: c
     :start-at: It is possible for a sample to use a custom set of Kconfig fragments for a
     :end-before: set(ACI_CONF_DIR ${APPLICATION_CONFIG_DIR}/child_image)

doc/nrf/app_opt.rst → doc/nrf/app_dev/optimizing/index.rst

@@ -9,5 +9,5 @@ The following user guides show how you can optimize your application.
    :maxdepth: 2
    :caption: Subpages:
 
-   app_memory
-   app_power_opt
+   memory
+   power