Set up CI and package build

See merge request !3

It takes ages and is not necessary on tag builds.

We rely on conventional-commits commit messages to auto-generate the
release changelog with release-it, so we need to ensure commits use this
pattern.

The package is published by CI on tagged commits. The `npm publish`
command is only allowed to run if the package version hasn't already
been published, and if the current commit is git-tagged with the same
version as in package.json. This happens via the package.json
prepublishOnly hook, and skipping already-published versions via the CI
step that runs npm publish.

Tags will be created by release-it separately.

We're no longer using the @ucam org for UIS DevOps things.

Lock file was not up to date too.

This mui-theme-example dir contains a simple React app, built with Vite,
that imports the theme as a module, and uses the theme plus some
components we export. It's both a demonstration of how to use the theme
package, and an integration test that shows the package is working as
expected.

Our @ucam/mui-theme package now defines exports with a specific structure
to define how theme users import components, and how the theme's internal
modules are structured. Users can only import modules explicitly
exported by package.json#exports.

We have the following exports:

  - @ucam/mui-theme/package.json
    (In case it's useful in some way, could have additional metadata in
    here for theme users...)
  - @ucam/mui-theme
    The package root, things explicitly exported from src/index.ts
  - @ucam/mui-theme/*
    Subdirectories under src/ that contain an index.ts, these exports
    contain just the things exported by the associated index.ts file.
    These are used to import components, for example, see the current
    placeholders:
    - `import { TestButton } from "@ucam/mui-theme/placeholders/TestButton"`
  - @ucam/mui-theme/fonts
    This is a special case. It contains the asset imports for fonts used
    by our theme/Material UI. It seems sensible to allow theme users to
    import it explicitly, as it'll be imported for side-effects and
    handled by their build system.

Rather than targeting web assets (js bundles, etc), the primary project
build is an NPM package that will be a dependency of other projects that
are building themselves as web assets. As a result, we don't use vite in
our own build, rather we use typescript/tsc to create individual ESM
modules with .d.ts types, .map source maps, and the source files (from
./src/ which are referenced from the .map files).

We don't bundle our Storybook stories with the NPM package as they're
not required to use the theme, but it's possible that downstream
projects that have their own Storybooks might like to have our stories
show up in their Storybook, so we could revisit this and consider
packaging our stories, perhaps as a separate package.

We format JSON with prettier instead.

The imported storybook config seems to expect to be included at the top
level.

This is a NPM library package, so we don't want/need a container image.

It has the standard checks from uis/devops/webapp-boilerplate, plus
eslint & typescript checks from package.json.

We're going to build and host the storybook for branches, to preview the
changes made in a branch. And the main branch will be published at the
root of the repo's GitLab Pages site.

Could be useful to compare the default with ucam.

Via `npm create storybook@latest`.