* Add GCF VM Delete Event Handler Example

Customer use case: When a VM is deleted, DNS A records associated with the VM
should be automatically deleted so that stale DNS records do not pile up.

The customer requested the solution be general enough to support VMs deleted
through the Console UI, gcloud, Deployment Manager, Terraform, etc...

The solution uses a GCF Background Function handling `compute.instances.delete
events`.  The customer also required the function compare the IP address of the
VM's primary interface with the DNS A record rrdatas to guard against deleting
the incorrect record.  This IP check introduces a race condition, the function
races against the VM delete operation.  In practice the function wins the race
most of the time and the cleanup is successful.

* Improve log UX when DNS cleanup fails for reason IP_NOT_AVAILABLE

This patch is intended to enable the customer to easily identify when
the DNS A record cleanup is not performed because the IP address cannot
be determined.  The goal is to provide structured data to easily filter
and identify VM instances which did not have their A record deleted.

The reason: 'IP_NOT_AVAILABLE' key/value is intended to provide this
filter.

* Refactor to DnsVmGc app class and structured logs

App class
---

This patch refactors GCF function into a DnsVmGc class.  Instances of
this class are intended to have the same lifetime as the GCF background
function process.  API discovery happens once during cold start and is
re-used across multiple trigger events.

The EventHandler class models a single event processing execution.
Helper methods ensure results are reported consistently via the
`log_struct` method.  Result logs are logged into the
`reports/dns_vm_gc` stream.

Structured Logs
---

Without this patch the log structure data is sprinkled throughout the
code.  This is a problem because it's tangled up with the behavior,
instead the structured logs should be considered a contract with the end
user who will generate reports based on the logs.

This patch defines a set of StructuredLog sub-classes modeling the
structured log data.  This separates the log structure from the behavior
of the code, making it easier to change the behavior of the code without
affecting the log structure the user relies on.

Structured Logs are sent to the
`projects/$FUNCTION_PROJECT/logs/$FUNCTION_NAME` by default.  The output
stream is configurable via the DNS_VM_GC_REPORTING_LOG_STREAM
environment variable.