Fix non recursive folder delete using file system

[dfriederich]

Fixes #13349

Deleting a folder without recursive enabled failed as the used nodejs API unlink does not support folder deletion. Fixing it by first checking if it is a folder, and if so using rmdir instead.

Added a simple unit test, which also exposed that
the folder deletion also fails when using trash support, but that is a different issue.

What it does

Handle the deletion of a folder using the file system api.
Previously this did only work when asking to delete the folders content as well, now with recursive: false,
it does delete the folder if it is empty.

How to test

I did add a unit test, which fails without the fix.

Follow-ups

I did notice that when using the trash support, the deletion of a folder with content (recursive: true) did fail.

Review checklist

• As an author, I have thoroughly tested my changes and carefully followed the review guidelines

Reminder for reviewers

• As a reviewer, I agree to behave in accordance with the review guidelines

[JonasHelming]

@dfriederich Hi! If you mention "fixed #13349" in the description, an automatic link to the issue is created.

[dfriederich]

Fixes #13349

You want me to change the description? Or I see you manually added the reference in this PR, was that sufficient?
If I change it, should I change the one commit and force push, or create a separate commit and then we squash the commit message when/if merging? Or can we just edit the commit message when merging?
Sorry, don't know how github is setup for theia.

[JonasHelming]

Sorry for the confusion. What I meant is that if you mention "Fixes #xyz" in the description of the pull request (no necessarily the commit), Github will automatically link it on the issue. When I saw this PR I remembered that there was a corresponding issue. I searched for it and saw that you manually created a link over there so I thought, this information (auto linking) might be useful for you. We do not have strict rules about this, but traceability in both directions (PR<=>issue) is always good. Also, github will then automatically close the issue when this PR is merged.
Mentioning fixes #xyz is also good practice IMHO, but again we don't enforce this.

I believe Mark added the "fixes" tag in the beginning of the pull request description in the meantime.
I hope this makes sense! :-)

[dfriederich]

@JonasHelming Thanks for the tip :-).