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.

[thecraftianman]

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

Alright, I think I might've finally come up with a potential way to deal with this problem. It's a bit weird, but stick with me here. No matter what ID I tried in testing the length of a SteamID64 (ex. print(#util.SteamIDTo64("STEAM_0:0:0"))), it seems to always come out to be 17 characters long, and UniqueID (ex. print(#util.CRC("gm_".."STEAM_0:0:0".."_gm"))) seems to pretty much always come out to be 10 characters long. I added a metatable that is only used by ULib.ucl.authed to convert UniqueID usage to SteamID64 in its __index and __newindex methods using this length check to determine which one is being used, which should be more efficient than using player.GetByUniqueID or something else that would have to iterate over players in order to find the one with the matching UniqueID. This still isn't a great solution for when a UniqueID actually does get used because player.GetByUniqueID is still needed anyways to get the correct player, but it should at least prevent other addons from breaking. Let me know what you all think about this idea.