[Feature] Alternative response format for resources

[fmigneault]

Route GET /resources returns a large nested dictionary of resources.
It is useful for viewing the actual resource-children tree, but it is not practical for parsing because it has:

• duplicate information repeated in keys/parameters forming the mappings
• inconsistent format according to service/resource type at different level of the tree

Different query parameters should be added to obtain alternate and improved response formats (captured by order of priority, going to next if false):
0. nested=true|false (default, current format with different details of service+resource)

1. flatten=true|false to obtain a flat list of all resources (similar to [Feature] Alternative listing of services #345, but for services)
2. uniform=true|false to obtain unified tree of resources with same fields as nested components
3. combined=true|false to obtain some kind of mixed representation of flattened-resources as list, but which tree-hierarchy still represented, where each sub-resource container also being recursively a flattened-list, all using the same keywords and provided details.
4. style=nested|flatten|uniform|combined as other to capture values ?
5. if none provided, nested=true default

Current default nested format (backward compat):

resources: 
  <service-type>: 
    <service-name>:
      [service-specific-fields]
      [resource-specific-fields]
      resources: 
        <resource-id>: 
          [resource-specific-fields]
          children: 
            <resource-id>: 
              [... recursively other 'resource' ...]

With flatten=true, the list gets flattened as follows.
note: parent_id and root_service_id are in the resource fields, so it is still possible to infer the whole graph, just easier to parse

resources:
  - [resource-specific-fields]
  - [resource-specific-fields]
  - ... 

With uniform=true, the format remains as a tree of resources, but removes all the extra details specific to services.
Also, children are all replaced by resources to effectively allow one to have a recursive function to parse the tree.

resources: 
  <resource-id>: 
    [resource-specific-fields]
    resources: 
      <resource-id>: 
        [... recursively other 'resource' ...]

Finally, combined format:

resources: 
  - [resource-specific-fields]
    resources: 
      - [resource-specific-fields]
        resources: [...]
  - [resource-specific-fields]
    resources: 
      - [resource-specific-fields]
        resources: [...]