UCL improvements

[thecraftianman]

NOTE: This change also requires the matching ULX pull request to avoid breakage: TeamUlysses/ulx#226

This PR has two main changes that impact UCL:

• UCL networking updates no longer resend all player and group data at once; instead, only the data for the applicable player/group will be networked to users upon an update
  • To facilitate this, two new clientside functions have been added: ucl.updateClientUCLPlayer( id, data ) and ucl.updateClientUCLGroup( name, data )
• ucl.authed now uses SteamID64 internally instead of UniqueID
  • All functions that have been impacted by this change now support SteamID64 as a parameter as well, but all of this can be reverted if just using SteamID would be preferred

Tested both in a local server and on a public server for a couple weeks now with no regressions found.

[Reycko]

Won't this break ULX extensions that access ucl.authed?
ULib.ucl.authed[player:UniqueID()] wouldn't work anymore on those.

[thecraftianman]

That's true, I assumed that there was no need for other addons to access that table directly when I wrote this. Maybe it could just be able to use multiple player identifiers as a key like ULib.ucl.users instead?

[JarosLucky]

Hey, without call PLAYER:UniqueID() somehere in PlayerInitialSpawn before PLAYER.query. Hook call PlayerInitialSpawn sendAutocompletes, gives instant error.

[Reycko]

Won't this break ULX extensions that access ucl.authed? ULib.ucl.authed[player:UniqueID()] wouldn't work anymore on those.

Thought about it for a bit, got an idea for a (sorta) compatibility fix:

Using a metatable, we can make __newindex give/set SteamIDs internally even when UniqueIDs are passed.
Not sure about __index (getter), though.