rename colon to :, make other syntax call Base functions

[JeffBezanson]

Fixes #25947.

I can't see much reason to have : call colon, so this changes it to be like other operators and parse as a call to :.

The next commit changes the lowering of syntax that corresponds to function names to be "hygienic", i.e. always call Base. A long time ago I thought it might be a feature that a[i] could call a local function called getindex, but (1) that's probably not a good idea, and (2) we're not consistent about this, and most forms already called Base functions. This makes it totally consistent (unless I missed one).

The first commit is just a simple lowering bugfix.

[yuyichao]

Finally....

[mbauman]

Triage was tentatively in support, especially with Jeff's argument that this implements a very simple rule: if you see the name in the syntax, it's lexically scoped. If lowering introduces a new name, like how A[x] becomes getindex(A, x), then that getindex name should hygienically reference Base.

[StefanKarpinski]

I'm all for this change. It would be nice to have a consistent mechanism for overriding non-obvious lowering names, though. The current names are hcat, vcat, hvcat, adjoint, getindex, setindex!, getproperty and setproperty!. One thought I had was to have some special name like __operators__ which is set by default to a module with these names bound. But why not just allow overriding them individually then? Another thought I had was to lower calls to them to __vcat__, etc. but have exported aliases from __vcat__ to Base.vcat and so on. That way you can extend vcat by its normal name or replace it with a different function (in local or global module scope) by doing const __vcat__ = myvcat. This the local name vcat is what is called by normal explicit calls to the vcat function while the __vcat__ name is used for implicit calls to vcat introduced during lowering, which should be harder to override and also overridable independently from vcat.

[JeffBezanson]

There are more: broadcast[!], dotview, typed_hcat, typed_vcat, typed_hvcat, vect, string, getfield, setfield!. Then generator expressions are kind of a borderline case, calling Generator, product, Filter, Flatten, and collect. Then there are a couple other cases: literal_pow, the iteration protocol functions, and lastindex for end. So there's a question of where to draw the line.

The double underscore idea is not bad. We already do that for @., which parses to @__dot__.

[JeffBezanson]

I should know better than to put 3 unrelated commits in the same PR. Will split these out.

[mbauman]

Split into #26073, #26074 and #26380.