Consider moving Julia download away from LazyArtifacts about bridgestan

[roualdes]

I vote to just use ~/.bridgestan instead of Scratch.jl, lest we find later on some unknown unknowns about Scratch.jl and its personal philosophies. We theoretically know a lot about using ~/.bridgstan across various machines.

[WardBrian]

Definitely weird!

Our CI wouldn't catch this because we only test that the download succeeds, not the permissions of the files, but it sounds like this is a Julia 1.10 regression: JuliaLang/julia#52272

Maybe us putting something we want write access to into the artifacts directory is bad manners, I'm not sure. If so we could switch to what we do in Python etc and put it under ~/.bridgestan

@sethaxen originally added this feature for us so I'm going to ping him to see if he has any thoughts

[miguelbiron]

Ah! Nice find, it didn't occur to me that this would be affecting other packages... it definitely looks an important regression on Julia 1.10. Will keep digging to see if there's anything I can do on my end, thank you.

[WardBrian]

I got confirmation that we probably shouldn't be using the artifacts system for this: JuliaLang/julia#52272 (comment)

They recommended https://github.com/JuliaPackaging/Scratch.jl, which seems similar, but I'm leaning toward using ~/.bridgestan like we do in Python or R. Thoughts @roualdes @sethaxen?

[sethaxen]

I don't have any particular insight here. Perhaps a benefit of Scratch would be to reduce the maintenance burden of this package by outsourcing management to that package (including, it seems, auto-deletion of the scratch space if the package is deleted or if it hasn't been used in a long time). But if the R and Python versions are already managing ~/.bridgestan, doing the same with Julia brings consistency and shouldn't greatly increase the maintenance burden.