Make extension file path code use UnescapeBinaryURLComponentSafe().

It was using UnescapeURLComponent() to unescape most characters, but
leave path separators, ASCII control codes, and UTF-8 characters that
are unsafe to display in the omnibox unescaped. The last bit of logic
doesn't really make sense here, as those UTF-8 characters can be used
in file names, and it's also unusual to partially unescape a URL and
then use it for anything but displaying to the user.

This API makes ExtensionURLToRelativeFilePath() use
UnescapeBinaryURLComponentSafe() to fail in the case of escaped ASCII
control codes or path separators, and successfully decode the formerly
forbidden UTF-8 characters.

This CL is part of a project to clean up uses of
UnescapeURLComponent(), as it's been used for wildly disparate
purposes, and much of its logic is only suitable for cases where
we want to format a URL for safe display to the user. We want
to make it leave more weird characters escaped, but need to
eliminate usage of it in other contexts before we can do that.

UnescapeBinaryURLComponent() should be used instead in most cases,
particularly where URL_SPECIAL_CHARS_EXCEPT_PATH_SEPARATORS is in use,
as all consumers of that option seem to either be slightly buggy, or
don't actually need to leave any characters unescaped. The primary
cases where switching to UnescapeBinaryURLComponent() may cause
problems (without additional checks), are cases where unescaping
path separators or funky characters (like %01) is a problem. In those
places, we should generally use UnescapeBinaryURLComponentSafe() and
fail instead of partially unescaping a URL.

Bug: 849998
Change-Id: Iad43fe2a064766e5a0744cbd4be48ca40afd0e28
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1599992


Reviewed-by: Devlin <rdevlin.cronin@chromium.org>
Commit-Queue: Matt Menke <mmenke@chromium.org>
Cr-Commit-Position: refs/heads/master@{#660183}