Switch to API endpoint for calendar updates

[tidoust]

This update switches the logic that was driving a Puppeteer instance to create and update calendar entries to a less convoluted logic that leverages the newly available API endpoint.

The W3C_LOGIN and W3C_PASSWORD variable and secret are no longer needed with that new approach, but a new W3C_TOKEN secret needs to be set. That token is returned by the admin interface when a big meeting is created (and can be reset by an admin afterwards as needed).

The logic remains the same otherwise: calendar entries continue to get added to the description of an issue, and that information gets used afterwards to avoid duplicating calendar entries for a given meeting.

One thing still missing: The API endpoint does not yet allow one to check or uncheck the "Limit 'show' selection below to those people who registered..." option in the "Joining" section. That option needs to be checked for group meetings and restricted breakout sessions (if any). That option needs to be unchecked for breakout sessions otherwise. To be addressed by the Systems team. This PR should not be merged until that gets fixed (hence the "draft PR" status). Cc @jean-gui

Calendar updates get done by the CLI command as before, typically called through a GitHub workflow. A next iteration could perhaps run the update from the spreadsheet but:

1. The maximum execution time of an App Script is 6 minutes, and updating the calendar could potentially take longer (script needs to sleep between requests to avoid rate limits).
2. It may make sense to revisit how and where the URLs to the calendar entries get stored. For example, it would make more sense to store them more directly in the spreadsheet, but we probably still want them to appear in the description of the GitHub issue.

Additional notes:

• Previous code used to deal with the case "draft calendar entry needs to be deleted". This no longer works because the API endpoint does not allow to "delete" a calendar entry (and there's no way to "cancel" a draft entry). Given our current workflow where "draft" is a very transient status on the way to "tentative", we should hardly ever need that in practice.
• Previous code used to retrieve the name of breakout session chairs through the user's page on the W3C web site with Puppeteer. Puppeteer being no longer used, the code can no longer do that. That affects chairs of breakout sessions who chose not to link their GitHub profile with their W3C account. In any case, if they do not make the connection themselves, surfacing their name in the calendar entry was somewhat wrong.
• Initial test is very crude. It at least validates that the code produces a suitable structure for the endpoint.

[jean-gui]

One thing still missing: The API endpoint does not yet allow one to check or uncheck the "Limit 'show' selection below to those people who registered..." option in the "Joining" section. That option needs to be checked for group meetings and restricted breakout sessions (if any). That option needs to be unchecked for breakout sessions otherwise. To be addressed by the Systems team. This PR should not be merged until that gets fixed (hence the "draft PR" status). Cc @jean-gui

@tidoust You can now add a "big-meeting-restricted" property with two possible values, true or false under the "joining" section