Enhanced Querying, "Submodel" Support

[b5]

This PR brings some necessary enhancements to make sql_datastore support a more "natural" implementation of the datastore.Query command. It also establishes patterns for doing one-to-many style relationships by leveraging Key Paths.

Here's an example from an upcoming datatogether/archive pull request:

// in this example we have a parent model "Collection",
// a child model "CollectionItem"
// and we want to query for a list of up to 100 of the first 
// items for a given collection:
res, err := store.Query(query.Query{
  Limit:  100,
  Offset: 0,
  // CollectionItem keys take the form /Collection:[id]/CollectionItem:[id]
  // and Collections have the key /Collection:[id]
  // the Collection key is the prefix for looking up keys
  Prefix: collection.Key().String(),
  Filters: []query.Filter{
    // Pass in a Filter Type to specify that results must be of type CollectionItem
    // In abstract terms this combined with the Prefix query param amounts to querying:
    // /Collection:[id]/CollectionItem:*
    sql_datastore.FilterKeyTypeEq(CollectionItem{}.DatastoreType()),
  },
  Orders: []query.Order{
    query.OrderByValue{
      // order the collection by the "index" param.
      // this will translate in SQL to "ORDER BY index", so long as
      // the query the CollectionItem model passes back accepts it.
      // see sql_datastore.go for more info. 
      TypedOrder: sql_datastore.OrderBy("index"),
    },
  },
})

Breaking Changes

model.NewSQLModel(id string) is now model.NewSQLModel(key datastore.Key)

NewSQLModel used to be passed a string id value. The original intent behind this was to have consumers of the sql_datastore package do less work extracting Model ID's from keys. This turns out to not be enough information to support sub-model type relationships, where the parent ID is passed back in via the key path. So, this PR chances the interface to pass back the entire key. I think this is a better way to go.

[b5]

@whyrusleeping if you had two minutes to have a look at this, would be greatly appreciated!

[dcwalk]

Just a q: are there some more urgent TODOs (or all of them) that we should be pulling out as issues?

[b5]

All TODO's need to be addressed at some point, if it's "urgent" I tend to address it then & there. My main reasoning for using TODO is to manage technical debt by pointing out areas that need work.

By that logic all TODO's represent potential issues, all roughly in the realm of code quality. TODO's who's comments include phrases like "awful mess" or "remove this ugliness" are of a higher priority.

See also my comment on datatogether/archive#16

[dcwalk]

Added #3 to address my comment. good to go on my end for what that is worth

[b5]

Thanks! I'm going to merge on account of the age of this PR & modest approval from @dcwalk. I'll try to re-surface the concepts here through documentation in the near future.