[WIP] fix: updates for public server & client types

[techfg]

Important

This is a WIP and should not be merged

What does this PR do?

As described in #4401, there are several issues with the existing "public types". This PR is intended to be a short-term solution to surface the more common types so they can be consumed by uesio app developers.

1. This PR is not intended to solve all of the issues, only address the low hanging fruit until a permanent solution can be implemented (see chore: improve generation of server & client types #4422).
2. The approach exports everything inside of the existing files that were previously not exported. This should be an easier starting point to identify if there are any types that should not be exported.
3. Some "export" statements within the various namespaces and the default export in client were removed as they all seemed unnecessary either because the types exported were already named exports and/or there doesn't seem value in having a default export given everything is within a named export anyway.
4. Some types/functions were added, for example WireRecord.getId() - it's not 100% clear yet to me when getId() needs to be used by getIdFieldValue() but in certain situations, getId() seems needed (e.g., api.signal.run) and in others getIdFieldValue() is needed (e.g., getting route assignments).
5. merge/mergeString/mergeBoolean - Change was made to merge to take a Mergeable instead of a string and return a FieldValue instead of a string. The runtime behavior of this for any consumer won't change/break anything but the typescript will complain in the IDE due to the change in return type. This change was necessary for a couple of reasons: 1) the default component generated when creating a new component used mergeString which wasn't exported and if exported without changing merge, they would have the same signatures; 2) Could not change the default component to use merge because while the typing wouldn't error in a consumer project, it would in the uesio project itself; 3) merge actually does and should accept things besides strings since at runtime, there's no way to know what the user is going to input in a "merge" operation. Currently, I did not add mergeMap, mergeList, mergeDeep, etc. intentionally since until it's fully determined what the public merge API should be, felt it unnecessary to include these.
6. Eliminated types that were exported in multiple places to only being exported one (e.g., UC, UtilityComponent)

Testing

Manual testing using a workspace that has code that relies on many of the types that were previously exported and no more typing errors :)