SPIKE: consider pre-release syntax for UI module snapshots

This ticket is being creating because I don't want malc's suggestion in FOLIO-1344 get get overlooked:

I'm thinking that the way we version UI components in the CI needs to change. It doesn't make any sense to version a component in testing as v1.2.3000123 and then release v1.3.0. It would make more sense for a developer to version the component in Github as something like 1.3.0-SNAPSHOT before development for that sprint or feature branch begins - similar to the process the backend Maven developers use - The CI can then iteratively append build numbers to that i.e 1.3.0-SNAPSHOT.1 until the release is actually made for 1.3.0 or whatever. I know that there are some limitations to how NPM dependency resolution occurs with snapshot releases, but they may work in our favor with this model - TBD.

Use of this pre-release syntax will also enable our build numbers to adhere to semver. Currently our npm-folioci build numbers can be misleading at the patch segment. For example, version 1.2.3000123 generated from a package defining itself as 1.2.3, technically can be satisfied by a request for ^1.2.4. Also, determining compatibility with our own npm-folio can also be a challenge. For example, is 1.2.3000456 actually the CI build of 1.2.3 or a build working toward 1.3.0?

One challenge, as I understand from the earlier JIRAs on this topic (FOLIO-690 and FOLIO-696), is with pulling in the latest versions of stripes dependencies defined below the platform's package.json (eg. platform > ui-app > stripes-smart-components > stripes-components). Grouping our stripes-* dependencies (STRIPES-543) should alleviate this, by pointing the app/platform to a version/snapshot of the framework which takes care of the underlying dependencies.