support symlink directories

[HunterLarco]

As per #516, the current implementation fails when -source receives a symlink directory. In this PR we solve this by converting symlinks to realpaths when the config is normalized.

Limitations

This change only converts the value of -source to a resolved path. As a result, passing a directory OR symlink directory to -source will behave as expected. However, we leave the walk logic in deployer.go untouched. This means that if -source contains nested symlinks they will not be supported. In truth I feel this is fine, not only is this the current behavior of s3deploy, but likely out of scope for this change as we'd need to recursively walk symlinks and maintain a relationship between the symlinked paths and the original -source root directory.

Backwards compatability

Should impact no existing flows, just adds -source symlink support.

Example / How I tested this

go build

# Test symlink use case.
ln -s lib my-symlink
./s3deploy -bucket example-bucket -source my-symlink -try
rm -r my-symlink

# Test non-symlink use case.
./s3deploy -bucket example-bucket -source lib -try

[bep]

This is all fine, except this indented code block -- which I can see make sense in some situations, but not for a 3-4 line block like this.

[HunterLarco]

The only reason I did this is to scope "err" to avoid variable shadowing with line 263. I've removed the code block and altered line 263 so that it compiles. Let me know if you'd prefer a different approach