Move aiida.orm.data within the aiida.orm.node module

[sphuber]

Fixes #2200

This final move makes the hierarchy of all node modules and its sub
classes consistent. The Data and ProcessNode classes who are both
sub classes of the Node base class and are direct siblings live on the
same level in the hierarchy, direct within the aiida.orm.node module.

Note that because the type string of all Data nodes now will start
with node. instead of data., a data migration had to be added.

[coveralls]

Coverage decreased (-0.03%) to 69.682% when pulling c4bd515 on sphuber:fix_2200_move_orm_data into 631ff01 on aiidateam:provenance_redesign.

[sphuber]

@giovannipizzi this PR is good for review. I added the suggestion you made in #2401 to add a message to the load_node_class message in the case of an ununderstood type string. Again most of the work in this PR is moving files around and changing imports. The only really important thing to check are the migrations that I added. Please make sure that I got the SQL correct. I didn't have time to add actual tests. Feel free to add those before merging if you like, maybe you can do this with Conrad in the coding week.

FInally, the test at Jenkins is failing because of the bug we had before. I already opened this PR before #2401 was closed, so now I had to rebase this, but that leads to merging conflicts on the Jenkins server, because it does not automatically do a hard reset. If you can access the machine, you can run git reset HEAD --hard in the workspace of this PR, which should make it work again. I just don't think I have access

[giovannipizzi]

Mmm, I think the SQL is wrong (^ as line-start is valid for regex but not for LIKE, that only accepts % and _ - not putting a % at the beginning implicitly means "starts with").
I think then that it's best to wait and add a couple of tests - I'll work on the other issues and if I've time I'll add tests here. I hope that this will not create too many conflicts with the Node class migration to the new infrastructure...

[giovannipizzi]

At least the SQL needs to be adapted (see my comment above), I didn't do a full review yet.

[giovannipizzi]

All good

[giovannipizzi]

A comment: while technically the regex alone would be not fully correct (it should be '^data\\.' I think, as . matches any character) it's ok because the following WHERE clause does the right filter