fix(Sharding): strict type context and return

[kyranet]

Please describe the changes this PR makes and why it should be merged:

Right now, ShardClientUtil#broadcastEval and ShardingManager#broadcastEval's return types are the same as the callback's, as well as the context passed, however, the context data is serialized, and so is the return type.

This PR implements Serialized, which fixes this issue by converting rich types into their serialized counterpart.

Status and versioning classification:

• I know how to update typings and have done so, or typings don't need updating

[kyranet]

I'm unsure how to properly type the returns because of the worker mode:

discord.js/src/sharding/ShardClientUtil.js

Lines 92 to 95 in 985d4d6

	} else if (this.mode === 'worker') {
	this.parentPort.postMessage(message);
	resolve();
	}

process.send seems to JSON serialize values, however, the worker mode supports sending a lot richer data, as this is powered by V8's serder instead.

[iCrawl]

This needs a rebase.

[iCrawl]

Can't we just go with this for now, despite the worker mode and potentially wait for an issue in case anyone is using this to send more complicated data?

[LosTigeros]

What about executing functions that would return a Promise on the shard?
Can't this be like:

promises.push(Promise.resolve(sh[method](...args)));

This would work for normal functions and PromiseLike ones so broadcastEval script/fn argument could be either T or Promise<T>

[kyranet]

Yes, we can go for this for now, and if we wanted to make both consistent, we can always use V8's serialization API, which is what worker threads use, @iCrawl.

Nice catch @LosTigeros! I changed the return of the callbacks from T to Awaited<T>, so in case it's a promise, the promise's type is unwrapped. Also added tests to make sure they work as expected, see 52ec31f :)