General-purpose feature upgrades

[maxgreen01]

This PR implements some general-purpose features that I've added privately over my ~2 years of using this script. It also adds Google Clasp to the project (partly based on the experimental-reorg branch of the main repo) and renames the main files to be .gs instead of .js. Even if these structural changes aren't desired, it should still be easy to extract the actual feature upgrades in the main script files.

More specifically, within the main script files, this PR:

• Adds support for syncing to/from multiple Notion Databases (see Sync multiple Notion databases to Google #64)
  • This is done by allowing the user to input multiple database URLs (see next point), tagging all GCal events with the current DATABASE_ID, then filtering retrieved GCal events using this tag. This allows multiple DBs to sync to the same (or different) Google Calendars.
  • This is a breaking change in how database URLs are stored in Script Properties, as DATABASE_ID is replaced by any number of properties ending in DATABASE_URL_PROPERTY_SUFFIX (which defaults to "DATABASE_URL", but could probably be changed to "DATABASE_ID" for backward compatibility). Unfortunately, I can't make a PR to the wiki to indicate this proposed behavior change.
• Adds support for making certain Notion DBs ignore updates from GCal, i.e. only sync in one direction (builds on the multiple databases feature) via the DATABASES_IGNORING_GCAL_UPDATES variable
• Introduces a default calendar if one isn't specified in Notion, which can be changed in calendarIds.gs
• Does minor cleanup on a bunch of documentation and log messages

[hk21702]

Hello!

Thank you for the PR. Apologies for not noticing it earlier. For full disclosure I don't use Notion anymore, but I'll still try and take a look at this PR, it might just take a while.

From a quick scan, the diff is quite large, but most of that seems to stem from the conversion to using clasp and the dependency management that comes with it. Another significant portion is refactors for the admittedly not the best code. If possible it'd be easier to review if the PR was split in two between new features and the conversion to clasp (though the clasp commit should be revised to still ignore calendar ids).

Another thing to consider is that these changes will require wiki documentation changes. Unfortunately, like you mentioned, PRs aren't possible for GitHub wikis. But under the hood it is still git. So, if possible, please fork the wiki and link it afterwards for any documentation changes that should be merged, and I'll apply them manually.

[maxgreen01]

Totally understandable! I’m not totally sure how exactly to separate the commits from a Git standpoint without manually rewriting the contents, but you can view all the non-clasp changes with this comparison view.

Also, I've created a "fork" of the wiki on my repo as per your suggestion. I'll try to update the wiki soon, and I'll leave another comment here when it's ready.