move wg-polonius to t-types

[lqd]

As described in the initial t-types announcement/plans:

Another relevant working group is the polonius working group, which primarily works on the design and implementation of the Polonius borrow-checking library. While the working group itself will remain, it is now also under the purview of the types team.

This PR moves the WG under t-types rather than t-compiler. Note that the move is limited in what the team repo and website support (much like t-types' structure itself): subteams currently can't have working groups.

It's not a big deal:

1. we can still have the WG as a child of t-compiler in the team repository -- this is still ultimately true transitively :) -- and document that it's a t-types WG. This is what this PR does.
2. or, have the wg be a team. @fmease has recently made changes to allow subteams to have their own subteams.

Let me know what you think @nikomatsakis and @jackh726. It feels the WG structure has merit in this case, compared to making it a t-types subteam. It seems fine to me to document that this is a t-types WG, but still attach it to t-compiler in the existing data structure of the team repo and website UI.

(This ultimately feels fixable, but I'm not sure it's absolutely necessary right now)

[fmease]

Ah, in #1046 I only allowed subteams (like types) to have subteams but not working groups (like wg-polonius) since there isn't a nice way to render the latter on the website. If you find a solution to nicely render WGs of subteams on the website (see rust-lang/www.rust-lang.org#1857), you can just lift this restriction, I'd say.

You dropping kind = "working-group" makes the subsubteam check succeed (since you've essentially turned the WG into a team) but of course it makes the prefix check fail.

[lqd]

Thanks, I was looking at the PR to remove/update that limitation. Otherwise we'll just turn the WG into a team :)

[lqd]

Or just move it in spirit but not in the website structure for real: it's documented, but we don't need the UI to be fixed to explain the team structure per se. Much like t-types itself.

[jackh726]

Would love to eventually get proper support of this (and types as subteam of lang+compiler), but this is good for now :)