binding partition: Start enforcing minimum world age for constant bin…

[Keno]

…dings

Currently, even though the binding partition system is implemented, it is largely enabled. New const definitions get magically "backdated" to the first world age in which the binding was undefined.

Additionally, they do not get their own world age and there is currently no latestworld marker after const definitions. This PR changes this situation to give const markers their own world age with appropriate latestworld increments. Both of these are mandatory for const replacement to work.

The other thing this PR does is to remove the automatic "backdating". To see the difference, consider:

function foo($i)
    Core.eval(:(const x = $i))
    x
end

Without an intervening world age increment, this will throw an UndefVarError on this PR. I believe this is the best option for two reasons:

1. It will allow us infer these to Union{} in the future (thus letting inference prune dead code faster).
2. I think it is less confusing in terms of the world age semantics for const definitions to become active only after they are defined.

To illustrate the second point, suppose we did keep the automatic backdating. Then we would have:

foo(1) => 1
foo(2) => 1
foo(3) => 2

as opposed to on this PR:

foo(1) => UndefVarError
foo(2) => 1
foo(3) => 2

The semantics are consistent, of course, but I am concerned that an automatic backdating will give users the wrong mental model about world age, since it "fixes itself" the first time, but if you Revise it, it will give an unexpected answer. I think this would encourage accidentally bad code patterns that only break under Revise (where they are hard to debug).

The counterpoint of course is that that not backdating is a more breaking choice. As with the rest of the 1.12-era world age semantics changes, I think taking a look at PkgEval will be helpful.

[Keno]

Alright, this is probably too breaking as-is. Don't even need to look at pkgeval, since Documenter is unhappy also. That said, I still think the automatic silent backdating is too confusing. As a compromise, I think we can do the backdating, but emit a warning. When and if we turn off that warning (i.e. whether it's a warning or an error in the full 1.12 release or we wait until 1.13 or later), we can decide later. I will update this PR to re-instate the automatic backdating and then I will add the warning in a separate PR.