Update shared<T> require T is an identifer

[alexcrichton]

Previously T could be any arbitrary type which would allow parsing shared<shared<T>> for example but these are intended to only be used with one layer of resource handles so the contents of the brackets are now required to be a single identifier. Additionally during resolution/validation the identifier is required to not only be a type but additionally be a resource type.

[sunfishcode]

@alexcrichton We went back and forth on whether we should use types for resources, or specialize with the knowledge that handles only refer to resources. Our most recent reason for using types is that we want to use type exports to export these types, and that seems easiest if we have actual types everywhere we refer to them.

However we do it though, rejecting shared<shared<T>> is the right thing to do.

[alexcrichton]

Indeed! That all makes sense to me, and this shouldn't change anything about the representations here along those lines. All resources are still stored in the types arena as well as handles and such. The difference with this PR is that instead of parsing T in shared<T> as a type it's now parsed as an identifier, but everything else under the hood is the same-ish. Locations that previously processed a Type now process a TypeId instead because the T is known statically to always refer to something identified and not, for example, Type::U32 (as would be the case with shared<u32>)

[sunfishcode]

Ok, makes sense.