Merge ObjectSum and PolyTraitRef in AST/HIR + some other refactoring

[petrochenkov]

ObjectSum and PolyTraitRef are the same thing (list of bounds), they exist separately only due to parser quirks. The second commit merges them.

The first commit replaces Path with Ty in (not yet supported) equality predicates. They are parsed as types anyway and arbitrary types can always be disguised as paths using aliases, so this doesn't add any new functionality.

The third commit uses Vec instead of P<[T]> in AST. AST is not immutable like HIR and Vecs are more convenient for it, unnecessary conversions are also avoided.

The last commit renames parse_ty_sum (which is used for parsing types in general) into parse_ty, and renames parse_ty (which is used restricted contexts where + is not permitted due to operator priorities or other reasons) into parse_ty_no_plus.

This is the first part of #39085 (comment) and #39080 focused on data changes and mechanical renaming, I'll submit a PR with parser changes a bit later.

r? @eddyb

[eddyb]

This is getting awkward, I was trying to do this just today. Hopefully they're the same idea.

[eddyb]

I prefer TyPolyTraitRef to TyObjectSum - maybe TyTraitObject would be a good name?

[eddyb]

Ah, you changed the parser, more elegant than my lowering hack, heh. I'm not super sure about the changes to Vec and the name but everything else seems good to me.

[petrochenkov]

I prefer TyPolyTraitRef to TyObjectSum - maybe TyTraitObject would be a good name?

I actually thought about renaming it to something, but decided to avoid extra churn.
TyTraitObject/TyImplTrait looks good, another variant is TyTraitObjectSum/TyImplTraitSum.

[petrochenkov]

Renamed ObjectSum -> TraitObject

[eddyb]

@bors r+

[bors]

📌 Commit 66ef5f2 has been approved by eddyb

[bors]

⌛ Testing commit 66ef5f2 with merge a167c04...

[bors]

☀️ Test successful - status-appveyor, status-travis
Approved by: eddyb
Pushing a167c04 to master...