Usability improvements to display of array expressions

A related set of usability improvements to the display of arrays:

1. Add a 'expand all' option to open all child elements in the array
- Improves speed of searching through an entire array for specific values
- Not demonstrated in examples below
2. Add support for limiting the set of child members displayed
- As (1) this improves looking for specific values
- Also makes it easier to see patterns in data
3. Add an option to make the 'public' elements as tags on the children in that set
- The extra element just makes reading through large arrays more difficult
4. Add a method to limit the set of array elements to view
- Again browsing arrays would be easier.
- Something like [START_INDEX...END_INDEX]
- Missing START_INDEX assumes 0
- Missing END_INDEX assume ARRAY_SIZE-1

GDB does not natively support any of this (well you can sort of emulate the subset of an array display with *(&[START_INDEX])@(END_INDEX-START_INDEX) ) so I think these will have to be implemented in the frontend.

Ex.
```
typedef struct
{
uint element_1;
uint element_2;
} el_1_2_s;

typedef struct
{
uint element_3;
uint element_4;
} el_3_4_s;

typedef struct
{
el_1_2_s lower_elements;
el_3_4_s upper_elements;
} el_node_s;

el_node_s elements[50];
```

In 'expressions':
```
----------------------------------------------
| elements[0...4]<.lower_elements.element_1> |
----------------------------------------------
- elements [5/50] el_node_s [50]
+ [0] lower_elements.element_1 uint
+ [1] lower_elements.element_1 uint
+ [2] lower_elements.element_1 uint
+ [3] lower_elements.element_1 uint
- [4] el_node_s
- lower_elements {...} el_1_2_s public
element_1 uint
element_2 uint
- upper_elements {...} el_3_4_s public
element_3 uint
element_4 uint
-------------------------------------------------------------------------
| elements[0...4]<.lower_elements.element_1, .upper_elements.element_4> |
-------------------------------------------------------------------------
- elements [5/50] el_node_s [50]
- 0 {...} el_node_s
- lower_elements.element_1
- upper_elements.element_4
- {...}
- lower_elements {...} el_1_2_s public
element_1 uint
element_2 uint
- upper_elements {...} el_3_4_s public
element_3 uint
element_4 uint
- 1 {...} el_node_s
- lower_elements.element_1
- upper_elements.element_4
+ {...}
- 2 {...} el_node_s
- lower_elements.element_1
- upper_elements.element_4
+ {...}
- 3 {...} el_node_s
- lower_elements.element_1
- upper_elements.element_4
+ {...}
- 4 {...} el_node_s
- lower_elements.element_1
- upper_elements.element_4
+ {...}
```

As it stands you have something like this:
```
------------
| elements |
------------
- elements [50] el_node_s [50]
- 0 {...} el_node_s
- public
- lower_elements {...} el_1_2_s
- public
element_1 uint
element_2 uint
- upper_elements {...} el_3_4_s
- public
element_3 uint
element_4 uint
+ 1 {...} el_node_s
+ 2 {...} el_node_s
+ 3 {...} el_node_s
+ 4 {...} el_node_s
...
```
Which to view a single value is 4 clicks per entry and it is 6 to display all values.

Start at the frontend expressions view and trace how GDB array values are currently rendered and expanded. Compare that behavior with the four requested array controls, then define a focused scope and verify that the resulting view supports the requested browsing behavior without relying on changes to GDB.

Written by the indexing model from the issue text.