Add app-level startup hooks

[hossam-nasr]

Partially implements #539. This PR builds on the work to add invocation hooks (#548) and to support app-level code (#576), to provide the ability to register app startup hooks, which are run in workerInitHandler (or functionEnvironmentReloadHandler in the specialization scenario).

In addition, some additions/decisions in this PR, which may require more discussion:

• An app teardown hook is not provided for now, since the Host does not yet support the worker_terminate signal for elegant shutdown of the worker. This issue is currently being worker on in the host (Add support to gracefully shutdown language worker azure-functions-host#2308 and Added support to gracefully shutdown language worker azure-functions-host#8385). Once this issue is implemented, a handler for the worker_terminate gRPC message can be added to add app teardown hooks.
• Added a logger property to HookContext, which allows all hooks, including invocation and app startup hooks, to emit user logs to app insights.
  • Pros:
    • Provides a clear and recommended way to emit logs to app insights from hooks, including app startup ones
    • Allows users to choose the log level, which will be honored in app insights
    • Includes extra metadata in the logs (such as function invocation ID for invocation hooks)
  • Cons:
    • Right now, for invocation hooks, users can already access the same functionality using hookContext.invocationContext.log. Duplicating properties is bad design.
    • If we include this property in the worker core API, it will be harder to change/remove in the future
    • Right now, logs emitted from app startup hooks will be ignored by the host, as they will be treated as "orphaned" logs, without a function invocation ID attached to them. Including this property before the Host can support logging from outside a function invocation, which will essentially do nothing, can cause confusion.
• The AppStartupContext provided to app startup hooks also includes a hookData property. That hookData property is copied to invocation hooks' contexts' hookData property, but cannot be directly modified by each invocation.
  • Pros:
    • This hookData property can in the future be shared between app-level hooks, such as app teardown hook.
    • Allows sharing of data between app-level and invocation-level hooks
  • Cons:
    • If the data is merely copied to each invocation hook, maybe this isn't necessary, and users can just use global variables instead.

[ejizba]

I think we already discussed all of this offline, but just documenting what I think is left for the PR

[hossam-nasr]

Addressed most comments, should be ready for another pass :)