Contract docs: Table contract

[yesoreyeram]

This PR adds proposal for table kind contract with two formats ( table plain and table frame ).

Why this is required

If a data frame doesn't falls under timeseries, numeric or any other known kinds, By specifying this as table kind will let the consumers know how to handle it without any guess work. Say example, when a frame have three fields ( date-of-birth (time), name(string) and age(number) ), it can be easily misinterpreted either as timeseries or numeric. So by specifying table kind, consumers can handle this without confusion.

Why two different formats

This PR proposes two different format (table plain and table frame ) under table kind.

By specifying table plain it will become clear that the consumer doesn't need to handle any fields. This format can simply act like a sql table/database.

By specifying table frame it will become clear that the data is not timeseries/numeric or any other known formats. Also it is clear that the data require some post processing due to the presence of labels.

Looking for feedback.

[kylebrandt]

I think the unique name requirements should perhaps be removed. At least in terms of table responses from SQL, something like Select 1 as "A", 2 AS "A", although odd, is valid.

To work with data like this in terms of manipulation we would need positional/ordinal selectors which we generally don't have now. But it seems like validate that would be at the time of input to an operation.

Do you have any different use cases for these formats (e.g. when would a datasource author attach which format to the frame?(I imagine perhaps based on a query option, so why would a user pick one over the other?)

[kylebrandt]

What might a labels on a field mean in the table case?