Settings hierarchy should be returned.

[caspiano]

Describe the bug

A ControlSystem associated with a Zone will not render the inherited settings from the Zone.

To reproduce

1. Place a ControlSystem in a Zone
2. Add settings to Zone
3. Attempt to view settings of ControlSystem

Expected behaviour

Zone's settings should be propagated to child systems/zones when rendered in backoffice.

Suggested fix

Currently, the settings for a model are only those that apply.
An additional route parameter include_hierarchy should be added to encapsulate the desired behaviour.

Additional context

PlaceOS/backoffice#216

[stakach]

following the discussion, potentially have two lists:

• explicit_zones: [level_3, system_type_2]
• zones: [org, building, level_3, build_2020, system_type_2]

where the zones list is generated by the api in API responses? (keeps the model logic simple as people change zone parents etc)

The driver logic in core relies on having the complete zones list, but could be a reasonably simple update by making def zones perform the lookups based on the explicit zones

Things to consider:

1. ordering is quite important when generating the zone list
2. updates to parent zones will need to trigger driver update logic for any children