Naming of unit name concepts

[jonaskello]

The unit today have several concepts to describe its name/identification:

• name field in the Unit type - Used as internal lookup identity, and for serialization.
• unit-name.ts module with getName function - Get name to display in UI, either derived or registered.
• unit-name.ts module with registerLabel function - Used to override derived name.
• symbol field in BaseUnit and AlternatveUnit type - used as fallback to build a derived name/label when no label is registered

To clarify what is what we should decide which concepts to keep and always use the same word to describe them.

• Rename unit-name.ts module to unit-label.ts
• Rename unit-name.ts module getName function to getLabel

For the symbol field we can either remove the function to have a fallback and default to blank when there is no registered label for a Unit, or we can rename this field to label.

[jonaskello]

Since we potentially want to move all the registries with global mutable state out of this package, it might be a good idea to keep symbol as-is on BaseUnit and AlternativeUnit and also keep the buildDerivedName function this package and export it for external use (it is a pure function that is not dependent on the registry). The function should be renamed to buildDerivedLabel or buildDerivedSymbol where the latter seems more logical since it uses the symbol field from the BaseUnit to build the result.

[jonaskello]

Since buildDerivedName is a pure function with only Unit as input it makes sense to move that function to the unit.ts module and export it from there (and also rename it to buildDerivedSymbol).