Add ability to distinguish between property, role, and state metadata

[rmeritz]

In order to create a more user-friendly test reports page, we want to allow users to filter data by role, property or state. (See #317 for a wireframe that includes the proposed filtering.) The idea behind this filtering is it would be a level of detail more useful for web-developers who are deciding to use a particular feature or not.

Currently, this data is included in refs column of the test.csv but it is not included in such a way that it could be clearly differentiated what data is a role, property, or state. (See https://github.com/w3c/aria-at/wiki/How-to-contribute-tests#refs). Currently, these properties are also included in the reference.csv file but no information is provided about if they are property, a state, or a role, just a link to an explanation of them on the aria practices site. (See https://github.com/w3c/aria-at/wiki/How-to-contribute-tests#refid)

Proposed Solutions:

1. Not add this feature and change the filtering on the reports page to allow filtering only by any reference. (At least for the next iteration of the reports page.)
2. Break the ref column into 3 separate columns for role, property, and state in test.csv
3. Break the ref column into 2 separate columns one for role and a second just for property and state in test.csv
4. Add new data into reference.csv such that for each refId there is a second value column that includes type info about the refId as well as the existing entry where the value is a link to the aria guidelines
5. Provide new generic metadata columns to test.csv like metadataKey1, metaDataValue1, metaDataKey1, metaDataValue2 etc. Such that a test contributor could add any set of additional attributes to a test.

It might be appropriate to just include this discussion as part of the other discussion currently being scheduled about the details of the test format. (See #337)

[mcking65]

Another option would be to use the role, state, or property name to query the spec and get whatever info you want about it using aria-query. Doing it this way avoids human errors that could creep in with the other options. This could also allow you to present a complete list and tell the user that there is no data for a specific combination of filters because you would have a complete list of all roles, states, and properties.