Version and State Information In Composite Environments

Today an Environment includes version and state properties but these properties don't make to much sense when using a composite environment. It might be better to move these properties to the PropertySource level.

Current:

{
   "name":"configurations",
   "profiles":[
      "default"
   ],
   "label":null,
   "version":"1e70e2f38b156fe222403262abe52de8eddbcb20",
   "state":null,
   "propertySources":[
      {
         "name":"https://github.com/ryanjbaxter/config-repo/application.yml",
         "source":{
            "info.description":"Ryans Spring Cloud Samples",
            "info.url":"https://github.com/spring-cloud-samples",
            "eureka.client.serviceUrl.defaultZone":"http://localhost:8761/eureka/",
            "foo":"from-default"
         }
      }
   ]
}

Proposal:

{
   "name":"configurations",
   "profiles":[
      "default"
   ],
   "label":null,
   "propertySources":[
      {
         "name":"https://github.com/ryanjbaxter/config-repo/application.yml",
        "version":"1e70e2f38b156fe222403262abe52de8eddbcb20",
        "state":null,
         "source":{
            "info.description":"Ryans Spring Cloud Samples",
            "info.url":"https://github.com/spring-cloud-samples",
            "eureka.client.serviceUrl.defaultZone":"http://localhost:8761/eureka/",
            "foo":"from-default"
         }
      }
   ]
}

Start by tracing how the Environment and PropertySource representations produce the current JSON, then compare that output with the proposed composite-environment shape. Determine how version and state should be represented for each property source and identify the relevant tests or entry points. Done means the response consistently exposes those fields at the PropertySource level without retaining the inappropriate environment-level values.