Add prototype of requesting metadata for a field

Nice start @manmorjim

Some general thoughts (sorry for the "parrafada")

the approach

In carto-js you just can ask a 'flexible query' for a source with dataviews (as for example in https://carto.com/developers/carto-js/examples/#example-formula-widget) but in VL the 'metadata' is strictly tied to the viz. It is internal also, and if you want to have some metadata for a field you must include it in the viz (let's say, "the styles"). In VL it has no interface as the one we're building now (but you can access some of it with functions like globalMin, globalMax....)... I like the carto-js flexibility / simplicity on this (but the performance in VL is bigger).

metadata interface

Regarding the Metadata definition, I think we should use a class, not an interface, and give it a bit more of 'content' / methods (that could wrap different requests or hold static values).

IMO we should probably end with a Metadata like:

metadata
    (a) global-related methods
    (b) field-related methods

What we need now to advance on styling is specially the (b) part, but this way we consider the whole context

a) global-related —> methods with info for the whole source
- number of rows
- bounds
- list of fields + type (?)
b) metadata for one field —> let's consider what applies for each type: number, string, date?
- what you currently have applies just to numbers and partially to dates, what about categories (string) fields?

I see something like this:

const fieldMetadata = aCARTOSource.metadata.getField(fieldName)

// which could return a FieldInfo object like...

{
 type: 'number, // a string or type with: 'number', 'string', 'date'
  // list of fields depending on the type... 
  min: 0,
  max: 100,
  avg: 50,
  sum: 300
}

In a DOSource I think that we have conceptually just one DOVariable per DOSource (thus 1 field), so maybe we could simplify and have just a aDOSource.metadata.getField() (without the field name).

field info

For numeric values those typical stats (min, max...) can be enough.
For category fields we are going to need a 'table of frequency' with the number of values per category.
We might need 'more' metadata for our internal uses (eg stDev, or even a 'sample' of records for local calculations), but the only way to know is to advance on next tasks, like classifiers for styling.

CartoDB / toolkit