permissions: Permit leading zero in YAML for octal notation

### Problem

I'm using the "permissions" plugin to set the correct file permissions on my Music collection. However, when setting the permissions value in the yaml file to "0644" and "0755", the following stack trace occurs.

If I set the values to "644" and "755", note the missing zeroes, it works just fine. However, permission values in octal are almost always written with a leading 0 to set the sticky bit correctly as well. While, most should not care about the sticky bit in this program, we should be allowed to write the permissions value with the bit stated.

Led to this problem:

```
Traceback (most recent call last):
File "/usr/bin/beet", line 11, in
load_entry_point('beets==1.4.5', 'console_scripts', 'beet')()
File "/usr/lib/python3.6/site-packages/beets/ui/__init__.py", line 1256, in main
_raw_main(args)
File "/usr/lib/python3.6/site-packages/beets/ui/__init__.py", line 1243, in _raw_main
subcommand.func(lib, suboptions, subargs)
File "/usr/lib/python3.6/site-packages/beets/ui/commands.py", line 934, in import_func
import_files(lib, paths, query)
File "/usr/lib/python3.6/site-packages/beets/ui/commands.py", line 911, in import_files
session.run()
File "/usr/lib/python3.6/site-packages/beets/importer.py", line 325, in run
pl.run_parallel(QUEUE_SIZE)
File "/usr/lib/python3.6/site-packages/beets/util/pipeline.py", line 445, in run_parallel
six.reraise(exc_info[0], exc_info[1], exc_info[2])
File "/usr/lib/python3.6/site-packages/six.py", line 686, in reraise
raise value
File "/usr/lib/python3.6/site-packages/beets/util/pipeline.py", line 358, in run
self.coro.send(msg)
File "/usr/lib/python3.6/site-packages/beets/util/pipeline.py", line 171, in coro
task = func(*(args + (task,)))
File "/usr/lib/python3.6/site-packages/beets/importer.py", line 1463, in manipulate_files
task.finalize(session)
File "/usr/lib/python3.6/site-packages/beets/importer.py", line 563, in finalize
self._emit_imported(session.lib)
File "/usr/lib/python3.6/site-packages/beets/importer.py", line 589, in _emit_imported
plugins.send('album_imported', lib=lib, album=self.album)
File "/usr/lib/python3.6/site-packages/beets/plugins.py", line 452, in send
result = handler(**arguments)
File "/usr/lib/python3.6/site-packages/beets/plugins.py", line 124, in wrapper
return func(*args, **kwargs)
File "/usr/lib/python3.6/site-packages/beetsplug/permissions.py", line 84, in fix
dir_perm = convert_perm(dir_perm)
File "/usr/lib/python3.6/site-packages/beetsplug/permissions.py", line 26, in convert_perm
return int(perm, 8)
ValueError: invalid literal for int() with base 8: '493'
```

Here's a link to the music files that trigger the bug (if relevant):

### Setup

* OS:
* Python version:
* beets version:
* Turning off plugins made problem go away (yes/no):

My configuration (output of `beet config`) is:

```yaml
lyrics:
bing_lang_from: []
auto: yes
bing_client_secret: REDACTED
bing_lang_to:
google_API_key: REDACTED
google_engine_ID: REDACTED
genius_api_key: REDACTED
fallback:
force: no
sources: [google, lyricwiki, musixmatch]
directory: ~/My_Music
threaded: yes

ui:
color: yes

import:
move: no
copy: yes
resume: yes
incremental: yes

plugins: web fetchart lyrics lastgenre lastimport duplicates discogs acousticbrainz missing scrub mbsync fromfilename thumbnails badfiles copyartifacts chroma permissions convert

clutter:
- Thumbs.DB
- .DS_Store
- '*.m3u'
- .pls
- '*.jpg'
lastfm:
user: darnir_redhat
api_key: REDACTED

paths:
ext:log: $albumpath/$artist - $album
ext:cue: $albumpath/$artist - $album
thumbnails:
dolphin: yes
auto: yes
force: no
copyartifacts:
print_ignored: yes
extensions: .cue .log .CUE .m3u
permissions:
file: 0644
dir: 0755
acoustid:
apikey: REDACTED
convert:
copy_album_art: yes
embed: yes
dest:
pretend: no
threads: 4
format: mp3
formats:
aac:
command: ffmpeg -i $source -y -vn -acodec aac -aq 1 $dest
extension: m4a
alac:
command: ffmpeg -i $source -y -vn -acodec alac $dest
extension: m4a
flac: ffmpeg -i $source -y -vn -acodec flac $dest
mp3: ffmpeg -i $source -y -vn -aq 2 $dest
opus: ffmpeg -i $source -y -vn -acodec libopus -ab 96k $dest
ogg: ffmpeg -i $source -y -vn -acodec libvorbis -aq 3 $dest
wma: ffmpeg -i $source -y -vn -acodec wmav2 -vn $dest
max_bitrate: 500
auto: no
tmpdir:
quiet: no

paths: {}
never_convert_lossy_files: no
album_art_maxwidth: 0
chroma:
auto: yes
lastimport:
per_page: 500
retry_limit: 3
duplicates:
album: no
checksum: ''
copy: ''
count: no
delete: no
format: ''
full: no
keys: []
merge: no
move: ''
path: no
tiebreak: {}
strict: no
tag: ''
scrub:
auto: yes
web:
host: 127.0.0.1
port: 8337
cors: ''
reverse_proxy: no
include_paths: no
missing:
count: no
total: no
album: no
lastgenre:
whitelist: yes
min_weight: 10
count: 1
fallback:
canonical: no
source: album
force: yes
auto: yes
separator: ', '
prefer_specific: no
acousticbrainz:
auto: yes
force: no
fetchart:
auto: yes
minwidth: 0
maxwidth: 0
enforce_ratio: no
cautious: no
cover_names:
- cover
- front
- art
- album
- folder
sources:
- filesystem
- coverart
- itunes
- amazon
- albumart
google_key: REDACTED
google_engine: 001442825323518660753:hrh5ch1gjzm
fanarttv_key: REDACTED
store_source: no
discogs:
apikey: REDACTED
apisecret: REDACTED
tokenfile: discogs_token.json
source_weight: 0.5
user_token: REDACTED
```

The traceback points to beetsplug/permissions.py, especially convert_perm, with permissions.file and permissions.dir in the YAML configuration reproducing the issue. Start by inspecting how those values are parsed before convert_perm receives them, then verify that 0644 and 0755 are accepted while existing values still work.

Written by the indexing model from the issue text.