Entity reference Computed Token Fields should behave like regular reference fields

I've been puzzling over this for awhile today, and as best I can tell this is really a Views-specific thing that we're missing, to wire up the Computed Token entityreference fields into the views_data_alter $data array correctly. I've managed to narrow down the core behaviour somewhat, and I believe the core views.views.inc is the key piece that adds the "X referenced by Y" relationships for entity_reference fields, and figures out which data table to join in based on the target_type of the field. What I can't see is why our Computed Token Field's aren't being recognized and included in there- we're obviously missing something, but I'm not sure what it is.

Possible we need to manually "wire in" the Computed Token fields in our existing computed_token_field.views.inc, which we've done for datetime fields. But I don't really understand what the shape of the $data array we should provide is. Alternately, perhaps our FieldType plugin just needs to implement some Interface it's not currently, or have an extra bit added to its Entity annotation, and it'll Just Work(tm). Any insights welcome!

Success! I'm pretty sure I got to the bottom of this, once I found that UserViewsData was providing the filter, and started tracing backward to the relationship that core entityreference fields end up getting in the ViewsData array. Eventually I landed on core_field_views_data() in views.views.inc (which looks like it's going away in D11?), and figured out that our computed token entity reference fields were not being handled by this core method (due to our "provider" not being "core", and a slight difference in the "target_type").

As such, I've pushed a patch that copy/pastes the same logic from core_field_views_data into our computed_token_field_views_data_alter() implementation, and it seems to do the trick. I'll do some further testing in situ, but it looks like this should do the tricky. Yay!