deprecate `&x` syntax in ccall, replace with Ref

[pygy]

|(::String) = 4
# | (generic function with 49 methods)

&(::String) = 6
# ERROR: syntax: invalid identifier name "::"

|(123,456)
#507

&(123,456)
# ERROR: unsupported or misplaced expression &

Base.(:&) works as intended.

[StefanKarpinski]

You need to put parens around some operators to use them in prefix form. I forget why this is, but it is the case for some operators and it's not a bug.

[pygy]

It's surprising that only some of them work without the parens. If it's not a bug, so be it.

I'm curious about the reason, though.

[StefanKarpinski]

It's because & as a unary operator is a special syntax that has meaning for ccall arguments. Since that's a very niche situation, however, I wonder if we couldn't allow prefix usage of the & function elsewhere.

[pygy]

You could mandate the parentheses for prefix & calls in ccall expressions, but not everywhere else.

The ccall section of the manual already documents special & syntax in that contex, a remark about prefix & calls could be appended to that paragraph.

[JeffBezanson]

Now that an alternative is available, we need to decide whether to fully deprecate & syntax in ccall.

[tkelman]

There's still a performance cost to using Ref in ccall right? Guess that needs fixing before & in ccall can be deprecated without performance regressions.

[StefanKarpinski]

There was a change to use Ref in the LAPACK wrappers and it was way too slow. I believe that performance issue is the blocker from completely removing the use of & in ccall.

[JeffBezanson]

#11402

[vtjnash]

need to deprecate & in ccall first, which is probably mostly pending #18632 right now (although that's not required for making this efficient – only need the easy case of #8134)