Hparams: Change some handling/generation of hparams with discrete domains.

[bmd3k]

This addresses several issues and cleanup related to how we generate and handle hparams with discrete domains:

1. From the backend, always return the list of discrete domain values for a string hparam. Previously we were returning no discrete domain values when the number of values exceeded 10 but this was breaking assumptions in the Angular hparam logic.
2. In the polymer UI, generate a "regexp" filter for discrete string hparams with greater than 10 values.
3. Fix regexp filter display logic in the polymer UI. We were never successfully showing the regexp filter. The check [[hparam.filter.regexp]] was incorrect since it would evaluate to false when regexp is the empty string. Instead we must check that hparam.filter.regex !== undefined.
4. Simplify the logic for generating discrete domain filters in the polymer UI - we just need to do it in a single place now that we can assume that the backend will always return the list of discrete domain values (thanks to item (1) and to previous work done in go/tbpr/6393)

[JamesHollyer]

These changes look good and should fix the issue. I believe this will potentially break the filter control in the runs table as it was not built to accommodate potentially hundreds of discrete values. So we need to make sure we fix that before launching.

I would also like to understand when the domain would be unpopulated.

[JamesHollyer]

I am not sure I understand this what is meant by an empty domain. I would expect this to always be populated.

[bmd3k]

It's possible, for example, in hparam summary api to specify that an hparam exists but not provide any values for it for any of the runs.

[rileyajones]

These changes look good and should fix the issue. I believe this will potentially break the filter control in the runs table as it was not built to accommodate potentially hundreds of discrete values. So we need to make sure we fix that before launching.

I would also like to understand when the domain would be unpopulated.

I am still not ready to send #6488 for review so I'll find some way to accommodate this issue prior to large numbers of discrete values prior to sending it for review.