contour lua does not work with separate build directory

[op3]

When using contour lua, files named <jobname>_contourtmp<x>.dat and <jobname>_contourtmp<x>.lua are created. Example code (mwe.tex):

\documentclass{standalone}
\usepackage{pgfplots}
\pgfplotsset{compat=newest} 
\begin{filecontents}{data_test.dat}
0 0 3
0 2 1
0 3 2

1 0 1
1 2 2
1 3 2

2 0 1
2 2 2
2 3 1
\end{filecontents}
\begin{document}
\begin{tikzpicture}
\begin{axis}
\addplot3[surf] table {data_test.dat};
\addplot3[contour lua={levels={1,2,3}}] table {data_test.dat};
\end{axis}
\end{tikzpicture}
\end{document}

Compiling this example works, and the two files mwe_contourtmp0.dat and mwe_contourtmp0.lua are created in the current directory.

When using a separate build directory, however, compiling fails. Commands:

lualatex --output-directory=build mwe.tex

or

latexmk -outdir=build -pdflatex="lualatex" mwe.tex

Relevant log excerpt:

PGFPlots: reading {data_test.dat}
Package pgfplots info on input line 21: Using 'lua backend=false' for plot 1 (t
ype 'contour external'): plot handler does not support LUA.

\openout3 = mwe_contourtmp0.dat
PGFPlots: reading {data_test.dat}

\openout3 = mwe_contourtmp0.lua
[\directlua]:1: module 'mwe_contourtmp0' not found:
	no field package.preload['mwe_contourtmp0']
	[kpse lua searcher] file not found: 'mwe_contourtmp0'
	[kpse C searcher] file not found: 'mwe_contourtmp0'
stack traceback:
	[C]: in function 'require'
	[\directlua]:1: in main chunk.
\pgfplotsplothandlersurveyend ...ur external/cmd}}
                                                  \else \pgfplots@error {Cal...
l.21 ...lua={levels={1,2,3}}] table {data_test.dat};
                                                  
The lua interpreter ran into a problem, so the
remainder of this lua chunk will be ignored.


./mwe.tex:21: Package pgfplots Error: sorry, plot file{mwe_contourtmp0.table} c
ould not be opened.

As a workaround, symlinks can be created such that latex is able to find the files.

I assume contour gnuplot has the same issue.

[op3]

I just realized that this is a duplicate of #464