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

@@ -69,15 +69,15 @@ 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).
+appropriate developers.
 
 ![Binary package generation from source change](/images/workflow_binary-package-generation.svg)
 
 {{% notice info %}}
-Whilst the automated workflows described here provide a robust solution for
-ensuring package quality and modularity these workflows clearly do not meet the
+While the automated workflows described here provide a robust solution for
+ensuring package quality and modularity, these workflows clearly do not meet the
 needs of a developer actively developing or debugging a code base. To meet this
 need, Apertis provides tools to ease
 [development and testing of applications on top of Apertis]({{< ref "ade.md" >}})
@@ -97,11 +97,11 @@ bug fixes and security fixes with the efforts done by the wider Debian
 community.
 
 After OBS has finished building a package, the results get published in a
-Debian package repository. The open-source packages from Apertis can be found
+package repository. The open-source packages from Apertis can be found
 in the public
 [Apertis package repositories](https://repositories.apertis.org/apertis/).
 
-The packages in these repositories are then used to build images , suitable for
+The packages in these repositories are then used to build images suitable for
 deployment onto a variety of targets (such as reference boards or product
 specific hardware, virtual machines and container images).  This process is
 automated via a CI/CD pipeline that runs nightly.
@@ -109,7 +109,7 @@ automated via a CI/CD pipeline that runs nightly.
 ![Image generation from binary packages](/images/workflow_basic-image-generation.svg)
 
 Generating images does not involve rebuilding all the packages from source and
-can thus be done quite quickly and flexibly. The whole pipeline is controlled
+thus the process is fast and flexible. The whole pipeline is controlled
 through YAML-based [Debos](https://github.com/go-debos/debos) recipes (which
 are
 [stored in GitLab](https://gitlab.apertis.org/infrastructure/apertis-image-recipes))
@@ -128,7 +128,7 @@ packages from the same OBS binary repositories.
 {{% /notice %}}
 
 
-The overall strategy for building these deployments is to separate it in
+The overall strategy for building these deployments is to break it down into
 various stages, with each stage represented by a separate Debos recipe.
 
 ![Multi-stage image generation](/images/workflow_multi-stage-image-generation.svg)
@@ -136,7 +136,7 @@ various stages, with each stage represented by a separate Debos recipe.
 The process usually starts with the creation of early common stages (e.g. a
 common root filesystem), with later steps performing modifications to these,
 further adapting then for specific hardware (for example, adding
-hardware-specific packages for a particular SoC/platform, like a bootloader,
+hardware-specific packages for a particular SoC or platform, like a bootloader,
 kernel, codecs or GL stack). Steps may also be taken to modify the image to
 cater for different deployment methods, such as applying the transformations
 needed to make updates available through [OSTree]({{< ref "ostree.md" >}}) or
@@ -144,18 +144,18 @@ images capable of being later updated via OSTree.
 
 ![Multi-stage OSTree image generation](/images/workflow_multi-stage-ostree-image-generation.svg)
 
-This split allows the creation of just one SoC, platform or even board specific
+This split allows the creation of just one SoC-, platform- or even board-specific
 recipe which can be combined with a selection of more generic recipes to enable
 either a single generic recipe to be used to fulfill the same use case across
 multiple platforms or different generic recipes to be combined with the same
-platform specific recipe to use the ame platform for different use cases.
+platform-specific recipe to use the same platform for different use cases.
 
-For instance the `target` and `minimal` recipes for `arm64` could be combined
+For instance, the `target` and `minimal` recipes for `arm64` could be combined
 with the U-Boot and Raspberry Pi recipes to generate four possible combinations
 of flashable images, targeting either the Renesas R-Car or Raspberry Pi
 platforms.
 
-A GitLab CI/CD pipeline will periodically schedule a batch of tests against the
+A GitLab CI/CD pipeline periodically schedules a batch of tests against the
 latest images on the
 [LAVA instance hosted by Collabora](https://lava.collabora.co.uk). LAVA takes
 care of deploying the freshly generated images on actual target devices running