Refactor UUID definitions

[amrc-benmorrow]

Currently we have a large number of source files defining constant UUIDs. The original design was that these UUID definitions were generally supposed to be private to a particular application, hence defining them in the source for that app, but in practice nearly all have ended up shared with service-setup if nothing else.

This could do with refactoring. I think we need a @amrc-factoryplus/uuids JS library which defines all UUID constants used by ACS. These should be exported in a tree structure like the current service-setup UUIDs definition; there are far too many for a flat namespace. Some rationalisation should be undertaken regarding the naming; I suggest top-level headings of FPlus for the very general UUIDs currently exported by service-client, ACS for other cross-cutting definitions, and then service- or app-specific toplevels for UUIDs with narrower scope. The existing UUIDs export from service-client should then become a simple renaming of FPlus.

Looking forward it might be sensible to define the repo under lib in such a way that it can build libraries for multiple languages from a single source of truth (probably a YAML file). Making this work correctly would mean thinking about the build, if lib/uuids must be built before the other directories can include from it.

[amrc-benmorrow]

Another option might be to build the libraries to read the YAML file at runtime. But this means IO, and locating the file from an installed app, and other complications. From nice easy languages like JS and Python this will be straightforward but it might be harder from things like C# or Java.