HParam UI: update ColumnHeader type

[JamesHollyer]

Motivation for features / changes

The goals is to allow for dynamic HParam columns in the data table. This means that we cannot have an enum like ColumnHeaderType be the unique identifier for the column headers because we cannot encapsulate all possible hparams into an enum.

Technical description of changes

This change adds a name and displayName field to the ColumnHeader interface. The goal here is to make name be the unique identifier for columns. However, this PR does not use these fields at all. It simply adds them. THERE IS NO FUNCTIONAL CHANGE in this PR.

Upcoming changes will switch the code over to start using the name as the unique identifier and display the displayName.

(For POC to see how this change fits in googlers see cl/526767686)

Screenshots of UI changes (or N/A)

N/A

Detailed steps to verify changes work correctly (as executed by you)

POC works

Alternate designs / implementations considered (or N/A)

There were many alternatives considered. In fact I do not believe this is going to be the final structure.

One option is to remove the type and add a category field
export interface ColumnHeader {
name: string;
displayName: string;
Category: ColumnCategory(STATIC, HPARAM, METRIC)
enabled: boolean;
}

However, deciding how to calculate the value based on hardcoded name strings does not seem ideal.

Another option is to have a hierarchy. I expect it to look like this:
Interface ColumnHeaderBase {
name: string;
displayName: string;
type: ColumnHeaderType;
enabled: boolean;
}

export interface StaticColumnHeader extends ColumnHeaderBase{
category: “STATIC”
}

export interface HParamColumnHeader extends ColumnHeaderBase{
category: “HParam”
source: enum(data, config,....);
differs:boolean;
}

ColumnHeader = StaticColumnHeader | HParamColumnHeader

This may be the final form that we go with however, we are not sure the source and differs attributes need to go here or somewhere else yet. All code which works with the type defined in this PR will work with this proposal as well.

Lastly, there is the option which is the same as the hierarchy option above but with StaticColumnHeader being the only interface with a "type" attribute. This is a valid possibility but, I have decided that it just adds unnecessary complexity by requiring a type check in many more places.

[rileyajones]

I am aware that this PR does not contain any real functional changes and that it is just adding some metadata in a bunch of places.

I have gone through and checked each of the enabled statuses in the tests and could not find any inconsistencies.

[rileyajones]

Was this unused before?

[JamesHollyer]

Sorry that should not have been in this PR. But, that is correct it was an unused import.