[PATCH] Fix non-ASCII cmdline options in non-UTF-8 locales

While reviewing r1475724 "Fix changelist filtering when --changelist values aren't UTF8", I noticed we also fail to convert some other command-line options to UTF-8. The attached patch addresses:   --old, --new:     Fix usage of non-ASCII paths. It looked for the wrong file and so was     unusable.   --search, --search-and:     Fix usage of non-ASCII search terms. It looked for the wrong text and so     was unusable.   --limit, --accept, --show-revs, --strip, --change:     Fix the error message shown for an invalid value. It showed the invalid     value using backslash-escape notation for the non-ASCII characters.   --file:     Fix the check for accidentally specifying a versioned file. It looked     for the wrong file and so typically would not trigger when it should.   --with-revprop:     - '=' characters are examined before converting to UTF-8; this should be safe becaue '=' is in the ASCII Basic Code Table [1].     - Property names are always converted to UTF-8; this is good.     - Property values are not; this would be wrong for svn:* props, but svn:* props are not currently allowed to be set by this method, so OK. Some other arguments, including '--native-eol', are not converted before testing for valid values, and the valid values are always ASCII.  This is OK, if we assume an ASCII subset.  That's probably safe, as [1] indicates that all common encodings except EBCDIC have an ASCII subset.  On the other hand, it does no harm to convert first, and doing so is more consistent with how we handle other options. Any comments? - Julian [1] ASCII IRV and BCT <http://www.debian.org/doc/manuals/intro-i18n/ch-codes.en.html#s-ascii>. -- Join WANdisco's free daily demo sessions on Scaling Subversion for the Enterprise <http://www.wandisco.com/training/webinars>