Decide on a strategy for filtering/sorting extra_attributes

[wadetandy]

Currently trying to sort or filter on something defined with extra_attributes will raise an error that the filter or sort is not defined. The DSL will accept both filterable: true and sortable: true arguments as an override, and while this removes the helpful error, it doesn't actually wire up the filters or sorts correctly so it blows up in a much less helpful fashion. We should be explicit about what we want to support here and provide useful errors when users try to do things outside of that.

Preserving the initial chat between me and @richmolj which spawned this issue:

@wadetandy: Just noticed that setting “filterable: true” on extra_attributes doesn’t actually create the filters as one would expect (though doesn’t yell at you either). Oversight or intended? If the former, we should extract this to a private method or something:
@richmolj: A little bit of each. Im not sure if this is in the docs, but extra attrs are read only.
Bc their orig use case was computed values, so you wouldnt filter on em
But i think the legacy id thing is a good use case to reconsider
I think there may be adverse effects of making them more than read only. At min that has to be the default
@wadetandy: Yeah, I could see basically raising an error if you provided a block AND filterable/sortable = true or something,
And disallowing writes