Updated README.md files to represent current code / use Markdown format

Previously, all of the README files have been renamed to README.md
and now, the contents of these files were changed to use Markdown
format. Other than format inconsistency, some README.md files lacked
information about modules, or were out of date. By using LibreOffice
/ OpenOffice wiki and other documentation websites, these files were
updated. Now every README.md file has a title, and some description.
The top-level README.md file is changed to add links to the modules.
The result of processing the Markdown format README.md files can be
seen at: https://docs.libreoffice.org/

Change-Id: Ic3b0c3c064a2498d6a435253b041df010cd7797a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113424
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>

1 files changed, 19 insertions, 20 deletions

diff --git a/stoc/README.md b/stoc/README.md
index 58f0c6f1a26a..47fd36d20fae 100644
--- a/stoc/README.md
+++ b/stoc/README.md
@@ -1,5 +1,4 @@
-Registries, reflection, introspection implementation for UNO.
-
+# Registries, Reflection, Introspection Implementation for UNO
 
 The UNO types and services bootstrapping code is very old, and concepts
 are tightly knit together. Whenever you want to change something you risk
@@ -9,32 +8,32 @@ up doing minimally invasive changes.  That way, you have a chance of
 surviving the process.  But you also pile up guilt.
 
 At the heart of the matter there is the old binary "store" file structure
-and the XRegistry interface on top of it.  At runtime, both all the UNO
-type information (scattered across a number of binary rdb files) and
-all the UNO service information (scattered across a number of rdb files
+and the `XRegistry` interface on top of it.  At runtime, both all the UNO
+type information (scattered across a number of binary `.rdb` files) and
+all the UNO service information (scattered across a number of `.rdb` files
 that used to be binary but have been mostly changed to XML now) are
-represented by a single XRegistry instance each.
+represented by a single `XRegistry` instance each.
 
-The way the respective information is represented in the XRegistry
+The way the respective information is represented in the `XRegistry`
 interface simply corresponds to the way the information is stored in the
-binary rdb files.  Those files are designed for storage of hierarchically
+binary `.rdb` files.  Those files are designed for storage of hierarchically
 nested small blobs of information.  Hence, for example information about
-a UNO interface type com.sun.star.foo.XBar is stored in a nested "folder"
-with path com - sun - star - foo - XBar, containing little blobs of
+a UNO interface type `com.sun.star.foo.XBar` is stored in a nested "folder"
+with path `com - sun - star - foo - XBar`, containing little blobs of
 information about the type's ancestors, its methods, etc.  Similarly
-for information about instantiable services like com.sun.star.baz.Boz.
+for information about instantiable services like `com.sun.star.baz.Boz`.
 
-As there are typically multiple rdb files containing types resp.
+As there are typically multiple `.rdb` files containing types resp.
 services (URE specific, LO specific, from extensions, ...), but they need
-to be represented by a single XRegistry instance, so "nested registries"
-were invented.  They effectively form a linear list of chaining XRegistry
+to be represented by a single `XRegistry` instance, so "nested registries"
+were invented.  They effectively form a linear list of chaining `XRegistry`
 instances together.  Whenever a path needs to be looked up in the top-level
 registry, it effectively searches through the linear list of nested
-registries.  All with the cumbersome UNO XRegistry interface between
+registries.  All with the cumbersome UNO `XRegistry` interface between
 the individual parts.  Horror.
 
-When the XML service rdbs were introduced, we chickened out (see above
-for rationale) and put them behind an XRegistry facade, so that they
-would seamlessly integrate with the existing mess.  We postponed
-systematic clean-up to the pie-in-the-sky days of LO 4 (or, "once we'll
-become incompatible with OOo," as the phrase used to be back then)
+When the XML service `.rdb`s were introduced, we chickened out (see above
+for rationale) and put them behind an `XRegistry` facade, so that they
+would seamlessly integrate with the existing mess. We postponed
+systematic clean-up to the pie-in-the-sky days of LibreOffice 4 (or, "once we'll
+become incompatible with OpenOffice.org," as the phrase used to be back then)