fix(licensing): add unityLicensingToolset input + fix HOME/USER under runAsHostUser

Addresses #739. Two opt-in, backwards-compatible changes for users on Linux
Docker builds with a Unity floating-license server:

1. Floating license servers that host multiple toolsets had no way to tell
   the Licensing Client which toolset to request — Unity could fall through
   to an entitlement that lacks build-target support (e.g. Android), then
   silently produce a Linux Standalone artifact. The action now accepts an
   optional unityLicensingToolset input that is written into
   services-config.json. When unset, the rendered config is byte-for-byte
   identical to before.

2. With runAsHostUser: true, su was invoked without explicit HOME/USER, so
   the host user inherited root's environment (HOME=/root, USER unset). The
   Unity Licensing Client, which writes to ~/.config/unity3d, could not
   resolve a writable home directory, leading to intermittent license
   activation failures. Set HOME/USER/LOGNAME explicitly before sourcing
   build steps. Change lives entirely inside the existing runAsHostUser
   branch.

dist/platforms/ubuntu/entrypoint.sh

@@ -71,8 +71,12 @@ if [[ "$RUN_AS_HOST_USER" == "true" ]]; then
   # Don't stop on error when running our scripts as error handling is baked in
   set +e
 
-  # Switch to the host user so we can create files with the correct ownership
-  su $USERNAME -c "$SHELL -c 'source /steps/runsteps.sh'"
+  # Switch to the host user so we can create files with the correct ownership.
+  # Pass HOME/USER explicitly so the Unity Licensing Client (which writes to
+  # ~/.config/unity3d) resolves a real, writable home directory rather than
+  # falling back to /home/UNKNOWN when getpwuid() inside the container has no
+  # entry for the host UID. -p preserves the rest of the env from root.
+  su -p $USERNAME -c "HOME=/home/$USERNAME USER=$USERNAME LOGNAME=$USERNAME $SHELL -c 'source /steps/runsteps.sh'"
 else
   echo "Running as root"