Place sentences in separate lines in READMEs (#113).

Having long sentences in READMEs makes them harder to change, and also makes
processing the diffs harder (among other disadvantages).

This commit implements the one-sentence-per-line principle, by placing
different sentences in separate lines in the README.

Author: ivanperez-keera

renode_rcc/README.md

@@ -1,5 +1,6 @@
 # renode-RCC
-Building [RTEMS Cross Compilation System (RCC)](https://www.gaisler.com/index.php/products/operating-systems/rtems), has a different directory structure compare to building RTEMS from source (might not be true). This will run RTEMS on leon3 in a renode simulation.
+Building [RTEMS Cross Compilation System (RCC)](https://www.gaisler.com/index.php/products/operating-systems/rtems), has a different directory structure compare to building RTEMS from source (might not be true).
+This will run RTEMS on leon3 in a renode simulation.
 
 ## Usage
 To run the simulator in docker container

spaceros/README.md

@@ -15,7 +15,9 @@ To build the image, run:
 
 The build process will take about 20 or 30 minutes, depending on the host computer.
 
-The build process defaults to cloning the `ros2.repos` file from [spaceros](https://github.com/space-ros/space-ros) repository. It looks for a branch with the same name as the current local branch; if it doesn't find one, it falls back to cloning from the main branch. For testing purposes, you can customize both the spaceros repository URL and the branch name by modifying arguments defined in the [Earthfile](./Earthfile).
+The build process defaults to cloning the `ros2.repos` file from [spaceros](https://github.com/space-ros/space-ros) repository.
+It looks for a branch with the same name as the current local branch; if it doesn't find one, it falls back to cloning from the main branch.
+For testing purposes, you can customize both the spaceros repository URL and the branch name by modifying arguments defined in the [Earthfile](./Earthfile).
 Example:
 ```bash
 earthly +image --SPACEROS_REPO_URL="https://github.com/my-org/my-spaceros-fork.git" --SPACEROS_GIT_REF="my-branch-name"
@@ -107,15 +109,17 @@ spaceros-user@d10d85c68f0e:~/spaceros$ colcon test --ctest-args -LE "(ikos|xfail
 
 The tests include running the static analysis tools clang_tidy and cppcheck (which has the MISRA 2012 add-on enabled).
 
-You can use colcon's `--packages-select` option to run a subset of packages. For example, to run tests only for the rcpputils package and display the output directly to the console (as well as saving it to a log file), you can run:
+You can use colcon's `--packages-select` option to run a subset of packages.
+For example, to run tests only for the rcpputils package and display the output directly to the console (as well as saving it to a log file), you can run:
 
 ```
 spaceros-user@d10d85c68f0e:~/spaceros$ colcon test --event-handlers console_direct+ --packages-select rcpputils
 ```
 
 ## Viewing Test Output
 
- The output from the tests are stored in XUnit XML files, named *\<tool-name\>*.xunit.xml. After running the unit tests, you can scan the build directory for the various *\*.xunit.xml* files.
+ The output from the tests are stored in XUnit XML files, named *\<tool-name\>*.xunit.xml.
+After running the unit tests, you can scan the build directory for the various *\*.xunit.xml* files.
 
  For example, a clang_tidy.xunit.xml file looks like this:
 
@@ -181,7 +185,8 @@ CONTAINER ID   IMAGE                   COMMAND                  CREATED
 d10d85c68f0e   openrobotics/spaceros   "/entrypoint.sh …"   28 minutes ago   Up 28 minutes             inspiring_moser
 ```
 
-The container ID in this case, is *d10d85c68f0e*. So, run the following command in the host terminal:
+The container ID in this case, is *d10d85c68f0e*.
+So, run the following command in the host terminal:
 
 ```bash
 docker exec -it d10d85c68f0e /bin/bash --init-file "install/setup.bash"
@@ -223,7 +228,8 @@ spaceros-user@d10d85c68f0e:~/spaceros$ colcon test --build-base build_ikos --ins
 ```
 
 The `colcon test` command runs various tests, including IKOS report generation, which reads the IKOS database generated in the previous analysis step and generates a JUnit XML report file.
-After running `colcon test`, you can view the JUnit XML files. For example, to view the JUnit XML file for IKOS scan of the rcpputils binaries you can use the following command:
+After running `colcon test`, you can view the JUnit XML files.
+For example, to view the JUnit XML file for IKOS scan of the rcpputils binaries you can use the following command:
 
 ```
 spaceros-user@d10d85c68f0e:~/spaceros$ more build_ikos/rcpputils/test_results/rcpputils/ikos.xunit.xml

zynq_rtems/README.md

@@ -4,7 +4,8 @@
 
 The goal is to create an hard real-time embedded application that runs on a Xilinx Zynq SoC FPGA which will communicate with Space-ROS.
 
-This demonstration will be on [QEMU](https://www.qemu.org), the open-source CPU and system emulator. This is for several reasons:
+This demonstration will be on [QEMU](https://www.qemu.org), the open-source CPU and system emulator.
+This is for several reasons:
  * Development cycles in QEMU are much faster and less painful than hardware.
  * Given the state of the semiconductor industry at time of writing (late 2022), it is nearly impossible to obtain Zynq development boards.
  * QEMU-based work requires no upfront hardware costs or purchasing delays
@@ -58,7 +59,8 @@ cd /path/to/zynq_rtems
 cd hello_zenoh
 ./run_zenoh_router
 ```
-This will print a bunch of startup information and then continue running silently, waiting for inbound Zenoh traffic. Leave this terminal running.
+This will print a bunch of startup information and then continue running silently, waiting for inbound Zenoh traffic.
+Leave this terminal running.
 
 In the second terminal, we'll run the Zenoh subscriber example:
 
@@ -78,7 +80,8 @@ cd hello_zenoh
 ```
 
 The terminal should print a bunch of information about the various emulated Zynq network interfaces and their routing information.
-After that, it should contact the `zenohd` instance running in the other terminal. It should print something like this:
+After that, it should contact the `zenohd` instance running in the other terminal.
+It should print something like this:
 
 ```
 Opening zenoh session...