Remove Entity ID field requirement

I'm going to nitpick this description apart, to possibly make clear what direction this can take:

The Data module is able to work with composite primary keys in combination with Views just fine - as in, it supplies standard views for displaying them. I'm doing it at the moment.
Also, the basic Data / Views integration has no reference to Entity IDs.

What you cannot do with these tables, is:

1) use the data_entity module / Entity API functionality. Because Entity API needs a single-field primary key. End of story.

2) use edit screens, and the 'Edit link' field from a view. Because... those screens are implemented in the data_entity module, and made to work with entities.

3) Quite possibly "stuff with joins". (I haven't figured the full depth of that rabbit hole yet. There are certainly bugs there, of which I'll file at least one.)

If what you want to do isn't "use edit screens" for this type of table, I'm not exactly clear on what is the issue.

For using edit screens... technically what needs to happen is porting them from the data_entity module to the data module. (And that they will end up not using entity IDs anymore, is kind-of a side effect.)
It would be a good addition to the module - I also don't like the requirement of making an entity type out of a table, just in order to be able to edit things. I'm also guessing that it isn't a huge amount of work.
(But I haven't needed it so far; I don't need to edit my composite-primary-key tables, I just created them in order to import data into them.)

OK, I've started needing it. So here's a patch which moves the edit screen from data_entity into data_ui, and enables editing on non-entities - including those with a multi-field primary key (or other unique index). It's based on #3151573: Move the concept of entity-ness into the main module which needs to be applied first.

I've chosen an approach where a key with multiple fields will need a URL to the edit screen which has the different field values in different path components. This drove the structure of some code.

The "Edit link" has also been moved to the data_ui module (which makes for simpler code because less hook_views_*_alter()s are needed). This means people's existing edit links in (customized) views will break. The code to handle the multi-value URLs is in a base handler now, which fixes #1488904: Edit link not working with relationships in views and #2990954: Make (views) edit link (field) text configurable at the same time, because it didn't make sense not to.

I've also ported the possibility to add new items (#2326857: Add/Create records form for entities) because it doesn't make sense to split that out into a different issue. The "Delete items" functionality (screen plus views link field) is also rolled into here; I can split it out if it's easier to review, but it's relatively little code compared to the rest.

This arguably still needs automated tests. (I've manually tested adding/editing/deleting entities, and items with a multi-field primary key.) Also, one might argue that this functionality needs to be created in D8 first, before applying this - I have no opinion on that.

Oops - left an option in the views handler that turned out to be unnecessary.

...and an unnecessary duplicate views.inc file :-(

(Indeed data_ui.views.inc is now not in the views/ folder. It does not get picked up from views/ automatically; the location doesn't work without specifying it as files[] in the .info file. So my conclusion is that it shouldn't be inside views/. It's not a class.)