Refactor async_hooks initTriggerId

• The first commit just renames initTriggerId to defaultTriggerAsyncId. I think default is much more descriptive and we try to never use just id in async_hooks but instead asyncId.
• The second commit changes the magic value from 0 to -1. This is because 0 in the executionAsyncId context refers to a missing context, while 0 in defaultTriggerAsyncId previously meant default context. This allows the defaultTriggerAsyncId to mean missing context too.
• The third commit is the main change. It changes defaultTriggerAsyncId from being set by the setter and reset by the getter, to instead have defaultTriggerAsyncId be bound to a scope. The getter then doesn't change the value. This is much more intuitive than getters mutating its own value. This is actually related to the work done by @refack in https://github.com/nodejs/node/pull/14302 but this is a much more complete version of that.

Note: All this is internal logic. However, in node v8.x and v9.x the initTriggerId is unfortunately exported (although deprecated), so properly we need to do a manual backport for those versions.

edit: Oh, the entire motivation behind this is that I want to improve some of our set triggerAsyncIds. However, in those cases, it is not transparent if a new handle is always created thus the kDefaultTriggerAsyncId value might leak. Binding kDefaultTriggerAsyncId to a scope prevents a leak.

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• tests and/or benchmarks are included
• commit message follows commit guidelines

Affected core subsystem(s)

async_hooks