user_schema() uses the wrong structure for foreign_keys

The current patch on #2883260: Replace the schema example with one actually used from a module uses the {users_data} table as the example in database.api.php, which is the source of the Schema API documentation. I am recommending a similar change there.

@kiamlaluno:

Thanks for looking at this, and for updating the issue title!

+    // For documentation purposes only; foreign keys are not created in the
+    // database.

I know that @alexpott, in [#2883260.11], says to keep that comment in the sample code in database.api.php, but I still think it is redundant. In this context, I can also argue for consistency: none of the other core modules have such a comment in their code.

+      'data_owner' => [

I guess that the key can be anything, but why "data_owner"? Do you mean that this is the users_data table, and this key identifies the user that "owns" the data in this table?

Looking at the other core modules,

• Some use the table name as the primary key in the foreign_keys array; here, that would be users. I do not like that much.
• The Shortcut module uses set_user, so maybe data_user would follow the same pattern.
• Similarly, the sessions table in the System module uses session_user.
• The node_access table uses affected_node, so affected_user would follow that pattern.

I suggest data_user or affected_user, but you can leave it as data_owner if you think that is clearest.

@kiamlaluno:

Thanks for the update. This looks good to me.