Rework workflow documentation

The workflow documentation is a bit of a mess. Rework the documentation:

• Split the details out of the platform guide, making it a better high level overview of Apertis targeted more at selling the platform.
• Create an architectural document covering the basics of the Apertis workflow and how the tools used by Apertis fit together. Use pictures to help explain.
• Detailed information about workflows shifted to guides
  • Packaging guide starting to be restructured to better cover workflows by adding sections.
  • Separating out description of component repository layout into its own guide.
  • Shift image creation details to Image building guide.

While I've noticed:

• Packages have been moved from repository based sub-directories under pkg/ to pkg/ its self. Update the URLs used on the website to reflect this.

Signed-off-by: Martyn Welch martyn.welch@collabora.com

content/architecture/workflow-guide.md

@@ -60,16 +60,16 @@ release branch.
 ![Branch testing and review](/images/workflow_review.svg)
 
 Automation is implemented via a GitLab CI/CD pipeline that performs sanity
-check builds of the components, on feature branches as well as release
-branches. When made to release branches, the pipeline takes care of uploading
-the updated source of passing changes to the
+check builds of the components on feature branches as well as release
+branches. When used with release branches, the pipeline takes care of uploading
+the updated source of changes passing the checks to the
 [OBS instance](https://build.collabora.com) (provided by Collabora) which
 takes care of automatically building the component sources for all the
 configured architectures (`x86_64`, `armv7l`, `aarch64`) and publishing the
 resulting binary packages in signed APT repositories. Each package is built in
 a closed, well-defined environment where OBS automatically installs all the
 build tools and resolves dependencies from a clean state using the packages it
-has built already: if any dependency is missing the build fails. Any build
+has built already: if any dependency is missing, the build fails. Any build
 failures are reported back to the relevant GitLab pipeline and to the
 appropriate developer(s).