[Tooling] GitHub to GitLab demo app migration

[pylapp]

Description

Today the whole project is hosted on GitHub, under MIT open source license or (proprietary for assets if noticed), except the CI/CD chain.
However the aim of OUDS is to expose also some brand themes like, we hope, Sosh, Parnasse, Innovation Cup, or other themes, and some of these themes may remain closed source under proprietary license and hosted in our internal GitLab forges so as to not expose assets, fonts, images or other resources.

Thus, we will have to make a migration, maybe for the v1 release, to GitLab for the demo app and keep there the CI/CD chain.
Today only alpha, beta and prod builds are made in our own runners in internal forge so as to keep the Apple certificates secrets and localy stored.

Because the update of the CI/CD chain and the migration of projects is a boring, time consuming and heavy task, it must be done if and only if some prerequisites are filled.

Definition of Ready

• Have a final name for the demo app ([Demo App] Renaming of demo application #85)
• Have the icons for alpha, beta, prod releases ([Demo App] Update the app icon with the new launch icon #140)
• Do not have big changes on going so as to prevent complexe rebase betwen branches

Definiton of Done

• Create in our GitLab a new project hosting the demo app (ouds-design-toolbokx)
• Close the old project for the CI/CD (ouds-ios-app-distribution)
• Migrate the demo app from GitHub to GitLab
• Update the GitLab CI chain to make alpha builds
• Update the GitLab CI chain to make beta builds
• Update the GitLab CI chain to make production builds
• Update the GitLab CI chain to leave tags on Swift package for nightly builds
• Prune the GItHub project so as to convert it as a "pure" Swift Package project, without demo app, NOTICES etx.
• Update the GitHub Action to run only builds and tests but not UI tests anymore
• Ensure we can use SwiftLint, Periphery, SwiftFormat, unit tests and documentation build for Swift Package
• Ensure we can use SwiftLint, Periphery, SwiftFormat and UI tests for design toolbox

Some details

• The GitHub repo must contain only the Swift Package
• We can keep ci and TestFlight tags for this repository so as to know which version has been shipped in nighlty process
• Release tags are done on the GitHub repository
• For the demo app we can give it the same versions as the lib (i.e. if lib x.y.z app is x.y.z)
• We keep alpha, beta and prod builds for the demo app
• For developement of features and fixes, given an issue number K with a branch K-foo-bar, both the demo app and the lib must have these branches.
• Alpha builds will consist on swiching to the suitable branch in the demo app, which points to the suitable branch on GitHub
• If we canot run tests or build doc on the Swift Package side, we will create a fake demo app just to fill these needs

[pylapp]

blocking beecause prerequisites are not filled, see definition fo ready

[pylapp]

cc @B3nz01d @ludovic35

[pylapp]

on hold as this is not mandatory at all, move to GitLab will imply to refactor the CI/CD pipelines and find workarounds for the alpha releases where the app will have to point to the SDK with the needed branch to test. Or maybe we will have to ensure the app will point to whatever the branch of the lib is, but in its own branche to compile.