Now I see that the PackageInstaller class in Orchard.Packaging.Services in the Packaging module does delete the module (or theme) folder. However its database traces and its content types still remain.
So the easiest approach would be to make a backend UI for this implementation, together with what the Delete Content Types module does (however I can't see any possibility to directly use this module, as the necessary code is written in a controller action,
not a separate class).
This would still leave some rows and tables in the database, which I'm not sure how to remove. Maybe the Orchard\Data\Migration\DataMigrationManager class can help, as there is an Uninstall method. However this would only run the Uninstall methods in the
migration class, what module developers are not required to write (and therefore never write as far as I can see). Fortunately this would still bring us closer to the solution as this would wipe out data migration entries from the database.
All in all, with my current knowledge: the deletion of the module folder, its content types (together with content items) and migration data is implemented and can be more or less used directly. The deletion of content parts is not implemented, but using
the ContentPartDefinitionRecord is could be easily achieved. The only flaw is that I can't see a way to delete the module's own tables.
However I think something like this should be an integral part of Orchard as directly deleting record entries looks a bit shaky for me.