bug: `retrieve` indicates success but results in an empty `targetDirectory` without any warning or error

[techfg]

When executing a retrieve, there are situations that can occur with the command indicating success in the logs but resulting in the targetDirectory (either current working directory or specified by --dir flag) being deleted and no files being written.

The situations are:

1. --since specified that results in no files - In this case, a warning should be given to the user indicating no files matched were found on server that have been modified since the specified date. Given the way the CLI behaves, deleting the directory anyway would be consistent but is a little odd. See feat: add ability to not "clean" target directory during retrieve #217.
2. Server returns a response GetRetrievePlan that contains skuidMetadataService and optionally skuidCloudDataService but all Metadata types are empty meaning there was nothing retrieved for any metadata type.

Regardless of which of the situations above occur, the user should be informed in an appropriate way (warning on expected and error on unexpected) so they are not left to wonder why everything was deleted, nothing is there and the CLI indicated it was successful.

Additional Information
Testing seems to indicate that even when a filter that was applied results in "no matches", the skuidMetadataService is always present in the response while skuidCloudDataService is null. This would seem to indicate that a response should always have a skuidMetadataService regardless of whether or not there was anything retrieved. What is the expected response when no results were found on server that match criteria (e.g., should there always be at least skuidMetadataService present)? Is there any situation where a skuidCloudDataService plan could be returned when skuidMetadataService is not?