Refactor pod IJOD comms; implement bounds,tardis

These operations are all really similar, so metaprogramming++.

On the pod side, all of these functions do the profile lookup and pod selection,
handling their errors identically. The only difference is `getRange`'s use of a
`cbEach`, so we handle that for the local IJOD call and when we get back a
remote `data` set.

On the service side, common ground is in parsing the parameters and returning
the response. Again the only difference is whether to accumulate and return
items from/for `cbEach`, so we do that when `getRange` requires it.

One functional change (vs. simple addition) from the previous code is in the
arguments to `cbDone` for `getRange`. I hadn't noticed the `ijod` response
there, which is used by `entries.runBases`. Now it's returned from the service
as `result`, which is needed by `getTardis` and `getBounds` to function at all.
Now for these three functions, `podClient` is indistinguishable in its responses
for local vs. remote data, as well as when compared to calling `ijod` directly.
Test `podClient.get{Bound,Tardis}`

I refactored the generic things that all three do, but left the specific pieces
duplicated for sake of explicit tests, though they're all quite similar.