commands: use a context manager for file I/O in debugdiscovery

check-seclevel: use a context manager for file I/O

largefiles: use a context manager in _getfile

util: replace file I/O with readfile

patchbomb: replace file I/O with util.readfile

util: adjust hgcmd() to handle frozen Mercurial on OS X Previously, 'hg serve -d' was trying to exec the bundled python executable, which failed with: Unknown option: -- usage: python [option] ... Try 'python -h'... abort: child process failed to start See the previous patch for details about the content of the various command variables. Note that unlike the previous patch here an application bundling Mercurial could set $HG in the environment to get the correct result, there isn't anything that a bundling application could do to get the correct result here. 'hg serve -d' now launches under TortoiseHg, and there is a process listed in the background, but a client process cannot connect to it for some reason, so more investigation is needed.

util: adjust hgexecutable() to handle frozen Mercurial on OS X sys.executable is "$appbundle/Contents/MacOS/python" when Mercurial is bundled in a frozen app bundle on OS X, so that isn't appropriate. It appears that this was only visible for things launched via util.system(), like external hooks, where $HG was set wrong. It appears that Mercurial also uses 'sys.modules['__main__'].__file__' (here) and 'sys.argv[0]' (in platform.gethgcmd()) to figure out the command to spawn. In both cases, this points to "$appbundle/Contents/Resources/hg", which invokes the system python since "/usr/bin/env python" is on the shebang line. On my system with a screwed up python install, I get an error importing the os module if this script is invoked. We could take the dirname of sys.executable and join 'hg' instead of this if we want to be paranoid, but py2app boostrap is setting the environment variable since 0.1.6 (current version is 0.9), so it seems safe and we might as well use it.

util: adjust 'datapath' to be correct in a frozen OS X package Apparently unlike py2exe, py2app copies the Mercurial source tree as-is to a Contents/Resources subdirectory of an app bundle, and places its binary stub in Contents/MacOS. (The Windows install has the 'hgext' and 'mercurial' modules in 'lib/library.zip', while the help and templates subdirectories have been moved out of the mercurial directory to the root of the installation. I assume that the python code living in a zip file is why "py2exe doesn't support __file__".) Therefore, prior to this change, Mercurial in a frozen app bundle on OS X would go looking for help *.txt, templates and locale info in Contents/MacOS, where they don't exist. There are only a handful of places that test for frozen, and not all of them are wrong for OS X, so it seems wiser to handle them on a case by case basis, rather that try to change mainfrozen(). The remaining cases are: 1) util.hgexecutable() wrongly points to the bundled python executable, and affects $HG in util.system() launched processes (e.g. external hooks) 2) util.hgcmd() wrongly points to the bundled python executable, but it seems to only affect 'hg serve -d' 3) hook._pythonhook() may be OK, since I didn't see anything outrageous when printing sys.path from an internal hook. I'm not sure if this special case is needed on OS X though. 4) sslutil._plainapplepython() is OK, because sys.executable is not /usr/bin/python, nor is it in /System/Library/Frameworks