More useful jump to error for `org-mode` source blocks

Currently we have the jupyter-org-error-location method which, depending on the kernel language, can parse a backtrace to figure out the line number where the error occurred.

Using Julia as an example, a typical backtrace looks like

BoundsError: attempt to access 5-element BitArray{1} at index [-1]

Stacktrace:
 [1] throw_boundserror(::BitArray{1}, ::Tuple{Int64}) at ./abstractarray.jl:538
 [2] checkbounds at ./abstractarray.jl:503 [inlined]
 [3] getindex at ./bitarray.jl:640 [inlined]
 [4] pivot!(::Array{Float64,2}, ::Array{Float64,2}, ::BitArray{1}) at ./In[217]:16
 [5] gauss_jordan!(::Array{Float64,2}, ::Array{Float64,2}) at ./In[157]:5
 [6] top-level scope at In[219]:7

When jupyter-org-error-location in a buffer with the above, it looks for the line containing top-level and parses the In[219]:7 to get a line number to jump to. Notice though that the actual error occurs in a different source block, the one corresponding to the line

 [4] pivot!(::Array{Float64,2}, ::Array{Float64,2}, ::BitArray{1}) at ./In[217]:16

It would be useful to have jupyter-org-error-location be able to return something like (COUNT . LINE) which tells the caller of jupyter-org-error-location to search for the source block associated with COUNT, i.e. the execution count, in the current buffer and jump to LINE in the code of the source block.

• In order to do this we would have to associate the execution-count slot of a jupyter-org-client with the source block, this can be done easily through text properties. We would then use next-single-property-change to search for the source block corresponding to COUNT.

Even more general would be to have jupyter-org-error-location return a function whose responsibility is to jump to the location of an error whenever called. This way jumping to an error would not be limited to just jumping to the source blocks in the buffer, but possibly to actual code files.

Maybe even to other org-mode files that contain source blocks that have been evaluated using the same client, e.g. if you call a source block using #+CALL: foo and the source block named foo lives in some other file. I think this is actually a separate issue though.

Does anyone else have suggestions on how jumping to the location of errors caused by source blocks could be improved?