Make sure jupyter runtime dir actually exists before trying to write connection file

[fmagin]

I don't know if there is a more elegant way to solve this, nor do I know when the IOException in createDirectories will actually be thrown, but this at least means that you can start a kernel and console on a freshly installed system that has never used Jupyter before.
The only user facing error before was a exception that the connection file was null, which and the issue that the connection file failed to write was only visible on the console.

[tmr232]

Looks good to me. Just making sure - did you check that the exception is reported in a meaningful way to the user now?

According to the docs, trying to create a directory where there's already a file in the same name should raise an exception, so we can test that:

Throws:
UnsupportedOperationException - if the array contains an attribute that cannot be set atomically when creating the directory
FileAlreadyExistsException - if dir exists but is not a directory (optional specific exception)
IOException - if an I/O error occurs
SecurityException - in the case of the default provider, and a security manager is installed, the checkWrite method is invoked prior to attempting to create a directory and its checkRead is invoked for each parent directory that is checked. If dir is not an absolute path then its toAbsolutePath may need to be invoked to get its absolute path. This may invoke the security manager's checkPropertyAccess method to check access to the system property user.dir

(from https://docs.oracle.com/javase/8/docs/api/java/nio/file/Files.html)

[fmagin]

I just checked the case that someone created a file called runtime at /home/user/.local/share/jupyter/runtime, then Ghidra does show a slightly more meaningful exception. But this is a fairly weird issue and means that someone went out of their way to mess with their Jupyter settings, so I guess we don't need to do more than making the exception visible.

I'm assuming an IOException wrapped in a RuntimeException will be similarly shown, though that's probably also more of a rare edge case.