Do not assign a default value to WakeLockRequestOptions.signal

[rakuco]

In Web IDL, the following WakeLockRequestOptions instances in JavaScript
should have the same effect (a dictionary that does not have the signal
member present):

{}
{signal: undefined}

which are different from

{signal: null}

which means a WakeLockRequestOptions dictionary with one member, signal,
whose value is null.

Setting a default value to the nullable member signal means we'd always
have a signal member in the dictionary even when we do not set it at
all (first 2 cases), which is not needed and does not make sense.

---

Preview | Diff

[kenchris]

This original change was requested by @marcoscaceres so he probably has comments

[marcoscaceres]

Setting a default value to the nullable member signal means we'd always
have a signal member in the dictionary even when we do not set it at
all (first 2 cases), which is not needed and does not make sense.

Agree. The problem was (is?) that the algorithm prose was defaulting it to null. If the prose doesn't do that anymore, then I'm ok with this.

However, I'd still like clarity on what happens when null is set. Why have nullable at all?

[rakuco]

However, I'd still like clarity on what happens when null is set. Why have nullable at all?

You have a point, I don't think this needs to be nullable at all. Most other occurrences of AbortSignal in a dictionary aren't nullable either, module Fetch's RequestInit.signal, and only because one can pass a Request to another Request's constructor.

I'll send a new PR making signal a regular member.