Order and conditionally show settings in the install form

[514sid]

Summary

Adopts two optional keys in the manifest's help_text schema so the install form matches what each widget actually uses:

• display_order sets the sequence fields render in, ascending within the basic and advanced sections separately.
• depends_on: {setting, values} hides a field unless a named setting currently holds one of the listed values.

Until now the form showed all thirteen settings for every widget, in whatever order they came back, with the applicable widget spelled out in each title and help text. Picking Crypto Heatmap still meant scrolling past a chart interval, a chart style, three toolbar toggles and a stock dataset picker, none of which do anything.

What changed

Eight widget-specific settings now declare depends_on: widget_type:

Setting	Shown for
symbol	Advanced Chart, Symbol Overview
interval, chart_style, allow_symbol_change, hide_top_toolbar, hide_side_toolbar, hide_legend	Advanced Chart
heatmap_dataset, heatmap_grouping	Stock Heatmap

widget_type, theme, locale, and display_errors stay unconditional. Every setting gets a display_order, contiguous 1..n within its bucket.

Resulting form per widget:

advanced_chart   basic: Widget Type, Symbol, Color Theme, Locale
                 advanced: Chart Interval, Chart Style, Hide Top Toolbar,
                           Hide Side Toolbar, Hide Legend, Allow Symbol Change,
                           Display Errors
symbol_overview  basic: Widget Type, Symbol, Color Theme, Locale
                 advanced: Display Errors
stock_heatmap    basic: Widget Type, Heatmap Dataset, Color Theme, Locale
                 advanced: Heatmap Grouping, Display Errors
crypto_heatmap   basic: Widget Type, Color Theme, Locale
                 advanced: Display Errors

Two smaller consequences:

• symbol and locale moved from plain-string help_text to the schema object form, the only place these keys can live.
• Dropped the "(Stock Heatmap)" title suffixes and the "the Advanced Chart widget" phrasing in help text, now that a field only appears for the widget it applies to.

screenly_qc.yml is regenerated from screenly.yml, so the two still differ only by id.

Notes

No src/ changes. Every setting is optional with a default_value, so getSettingWithDefault already handles a setting that isn't written because its field was hidden.

Unrecognized keys under help_text.properties are ignored, so on a console build without support for them the form falls back to today's behaviour rather than breaking.