Split export from non-export remote functionality

[mih]

Starting from #170 I waded through the special remote implementation. I cannot pinpoint it yet, but I believe ti is needlessly complex, because two different scenarios are supported by the same implementation. This imposes a needless complexity on consumers of the simple case.

Moreover, the current complexity imposed by the export functionality is not even delivering a sufficient set of functionality, because fundamental issues are unresolved (such as the file name mangling).

I thing the export-remote parts should be factored out, such that one can clearly see what is needed and what is an additional requirement for exporting.

This also includes the documentation: presently this is multiple pages of caveats. I sign that things are not in a good state yet.

[mih]

#101 is another use case for supporting different use cases with different implementations

[mih]

I have concluded my analysis on how datalad-dataverse should behave in non-export mode.

For export mode the situation is dire. Path mangling creates a situation that makes importtree unable to recreate a tree. #148 (comment) Moreover, implementing importtree is a fairly monumental development (across 2 or 3 packages). #146 (comment)

Given that, I think it would be sensible to clearly separate these two implementations, and also manage user-expectations properly