Add a backups config abstraction.

This abstraction helps address the problem of hard-coded paths for various sources from which backups pull data.  It also provides a better encapsulation of the information that drives backups.
Hmm.  You make an interesting point about just providing those two things directly to Backup() (or its successor).  You are right that, effectively, BackupsConfig is a synonym for "BackupsArgs".  (The question of struct vs. interface is orthogonal).  There are two differences from just passing the values in directly:

1. the signature of Backup() doesn't have to change if the required info does;
2. the config may include information that is relevant to some backups functionality but not to others (e.g. create vs. restore vs. list).

I expect some or most of the information encapsulated by BackupsConfig to be common between the different backups functionality.  So I'd rather keep all that information in a single type.