Add platform-specific settings to API model

[tjkirch]

Initially, this means setting "region" for the AWS platform.

The first use case is 'region' so we can regionalize container addresses; usage
will be controlled by variant-specific (and therefore platform-specific)
metadata, so a platform-specific setting path doesn't hurt. In the near
future, we will likely want to use region in other places, like telemetry,
where we don't want applications to have to understand platform; in this case,
we can abstract usage through a sundog generator that translates platform
specifics to application-specific settings.

Implementation is mostly in moondog. Previously, we only read user data, so it
needed some restructuring to handle other data in IMDS. Now, each platform
implements PlatformDataProvider. Its sole method can read user data or other
metadata however it likes, and just has to return a list of Settings-like
objects that it wants to be sent to the API.

---

Testing done:

The system is healthy, pods launch OK, moondog had no errors, and the new setting shows up:

[ec2-user@ip-192-168-33-74 ~]$ apiclient -u /settings
{
...
  "aws": {
    "region": "us-east-1"
  }
}

[zmrow]

🏔

[tjkirch]

This push addresses Ben's concerns by:

• making the identity doc optional like user data, because the user can disable the IMDS endpoint now with IMDSv2
• Making the "instance identity document" wording more consistent in messaging, and use shorter forms like "identity doc" in variables / places where space is at a premium

I made a new AMI to confirm things still plumb through.

[zmrow]

🗻

[tjkirch]

This push fixes the typo caught by @webern.