Refactor current implementation of storage jobs GetOutput

[jwreagor]

Currently, our implementation utilizing Manta's GetJobOutput() only returns a result set size header. The response is a stream to accommodate tail -f behavior and it doesn't look like we're returning the path to the Manta Job result object.

To illustrate, here's an actual request/response which includes the result object path...

GET /testacct/jobs/aabbccdd-0859-ccc2-d267-a2b4a0258eac/live/out HTTP/1.1
Host: us-east.manta.joyent.com
User-Agent: manta-go client API
Accept: */*
Authorization: Signature ...
Date: Thu, 27 Jul 2017 17:33:02 UTC
Accept-Encoding: gzip
Connection: close

HTTP/1.1 200 OK
Content-Type: text/plain
Date: Thu, 27 Jul 2017 17:33:02 GMT
Server: Manta
x-request-id: 142c4d40-7231-1de7-8bcf-2536c4d80c1b
x-response-time: 126
x-server-name: 3d2bcd91-5dd9-4e23-83a5-794144eab9fd
Transfer-Encoding: chunked
Connection: Close

/testacct/jobs/aabbccdd-0859-ccc2-d267-a2b4a0258eac/stor/reduce.1.359fdfda-53f1-40df-84d7-46b5040ea48a

From the above example, storage.GetJobOutputOutput{} (ripe for a rename) should include a field called ObjectPath which holds the value of "/testacct/jobs/aabbccdd-0859-ccc2-d267-a2b4a0258eac/stor/reduce.1.359fdfda-53f1-40df-84d7-46b5040ea48a".

Also, if we want to return the object, we could fire a subsequent Objects.Get and attach the returned storage.GetObjectOutput{} which contains an ObjectReader to the actual results. It might make sense to do this on behalf of the user at the cost of a second round trip (but that's debatable).