Tighten irregularities re: working directory and file search

If I have files:
subdir/a.vert
And I run:
glslc -c -working-directory subdir -o `pwd`/a.spv a.vert
Then when I run the following from /build/dir/ I get:
glslc: error: cannot open output file: 'subdir//build/dir/a.spv': No such file or directory

PR https://github.com/google/shaderc/pull/115 goes partway to fixing that but is confusing and looks like it has bugs.

The current description of output file placement has some missing cases and can be confusing.
This is a proposal at making it more regular. This is intended as comment to go above FileCompiler::GetOutputFileName in glslsc/src/file_compiler.h
It's text should also be used as the basis for an update to glslc/README.asciidoc

// Let "target directory" be the user-specified working directory, if
// provided, and the current working directory otherwise.
// Let "result extension" be ".spv" when generating a SPIR-V binary, and
// ".s" when generating SPIR-V assembly text.
// Let "resolved input filename" be the input filename if it's absolute,
// or the input filename appended to the target directory otherwise.
//
// If the user specified an output filename, then:
// If the specified output filename is an absolute path, then return that.
// Otherwise, return the specified output filename relative to the target
// directory.
// If the user did not specify an output filename, then:
// If linking is performed, return "a.spv" relative to the target
// directory.
// Otherwise, derive the output filename from the input filename as follows:
// If the input filename has a standard stage extension (e.g. .vert)
// then return the resolved input filename but add the result extension.
// Otherwise, return the resolved input filename but where its extension
// is replaced with the result extension. (If the resolved input filename
// does not have an extension, then append the result extension.)

This is very similar to Clang's behavior with -working-directory.
There's a small difference in that Clang behaves unexepctedly when both -o and -working-directory are
used with a relative path for -o.
For example, if I've got
subdir/x.c
subdir/subsubdir/
And I go:
clang -c -working-directory subdir x.c -o subsubdir/x.o
Then I get an error because the Clang driver is trying to make subsubdir/x.o without prepending the -working-directory subdir argument.

I found very few tests in Clang for -working-directory so I'll choose to interpret this irregularity as a missed case in Clang's implementation.