When removing a snap with aliases fails, aliases are not cleaned up, leaving the snap in a bad state

[Thomi Richards]

I recently attempted to remove the 'lxd' snap:

```
$ snap remove lxd
error: cannot perform the following tasks:
- Stop snap "lxd" services ([--root / enable snap.lxd.daemon.service] failed with exit status 1: Failed to enable: No such file or directory.
)
- Remove security profile for snap "lxd" (1743) (cannot find installed snap "lxd" at revision 1743)
- Remove data for snap "lxd" (976) (remove /var/snap/lxd/common/lxd/storage-pools/lxd/containers/snapdeltaservice: device or resource busy)
```

I've already filed a bug against lxd about the removal failing. After the removal failed, the snap was in the 'disabled' state:

```
$ snap list
Name Version Rev Developer Notes
core 16-2 1577 canonical -
lxd 2.8 976 canonical disabled
```

In an attempt to fix the first failure, I went to enable it:

```
snap enable lxd
error: cannot perform the following tasks:
- Setup snap "lxd" aliases (cannot create alias symlink: symlink lxd.lxc /snap/bin/lxc: file exists)
```

...and indeed the alias symlink exists, but it's dangling:

```
$ ls /snap/bin/
lxc
$ ls /snap/bin/lxc -l
lrwxrwxrwx 1 root root 7 Apr 6 17:57 /snap/bin/lxc -> lxd.lxc
```

manually removing the symlink and re-enabling the snap works.

I guess that if the 'snap remove' process encounters an error, snapd should attempt to clean up aliases before putting the snap into the 'disabled' state.

The output of 'snap --version' is:

```
snap unknown
snapd 2.23.6
series 16
ubuntu 16.10
```