subtask of RFC 195: Implement associated constants

[pnkfelix]

As a subtask of #17307, we want to implement associated constants at some point.

@aturon notes here that it probably need not block 1.0

This blocks the code revisions implied by #17825.

[seanmonstar]

Would this include constants in implicit implementations, or only when implementing a trait?

[eddyb]

@quantheory has done most of the work necessary in their associated constant branch, but it will not be trivial to rebase on top of #23265.

I think we should try and split those changes into "structural" (needed just because there's one more variant of impl/trait items) and "functional" (typeck::check, const_eval, check_consts, etc.).
(this can be done using git rebase -i and git gui or something similar to move parts of each commit into a second one)

After that, we'd have to redo the "structural" changes - I have most of those on top of my refactoring, but I'm not sure how well they'll fit.
@quantheory Is this good with you? How do you think we should split the workload? (I hope I'm not stepping on toes here, just want this done soon)

[eddyb]

cc @japaric @nikomatsakis (also see rust-lang/rfcs#865).
Relevant for numeric constants after #23104 and removing the modules they reside in.

[quantheory]

@eddyb I'd be interested in seeing what you have for the structural stuff. This is all (relatively) fresh in my mind, so I can tell what almost every change is doing (and whether or not we have a good reason to keep it at all) just by looking. Rather than first splitting the history into separate commits, and then doing a rebase onto #23265 as a separate step, I am tempted to rewrite the history into 2 themed commits and rebase onto #23265 at the same time (basically by hand). If you already have a structural commit more-or-less done, this would be simpler.

I think that I can get this done in a few hours here and there over the next couple of days. If I can get the rebase out of the way, we can split the remaining work just by looking at test cases. I have a significant list of things that I would expect to work, but haven't tried yet, and another list of things that need to produce appropriate error messages rather than ICEs. We can probably do some of those things in follow-up after the initial PR, but a few changes really should be addressed up front (like importing constants from another crate).

[quantheory]

Well, it took a little longer than I was hoping, but my branch is now rebased onto @eddyb's commit. (Of course it's still fallen a bit behind master in the meantime.) I still don't have cross-crate usage working. More info soon as I get some more tests done.