Site admins can view any org page, but shouldn't see a "Leave Org"
button unless they're actually members of the org.

Commented out for now because "orgs can own projects" PR needs to be
merged before this will compile.

This will be useful for enforcing GQL permissions such as "non-members
can only see the list of admins, members can see other members".

Non-org members are allowed to see the list of org admins, so we
shouldn't throw an exception here.

Now that the orgs are listed in the JWT, we could have a slightly
simpler implementation of the org.Members field GQL middleware.

We handle project claims specially because some users can be in many,
many projects, and so we need to squeeze every byte that we can. But for
orgs, most users will be in just one, and those who are in more than one
are usually going to be in just two or three. So we can just do a simple
array and let the standard JSON serialization handle it.

This allows org admins to see all projects, but org members just get to
see public projects the same way that non-members do (we might adjust
that in the future).

Now that these functions are starting to get quite long, they probably
belong in their own classes so that OrgGqlConfiguration stays readable.

Only site admins are allowed to retrieve users' email addresses, so only
site admins should be shown emails on the org page's members table.

There's no need to throw an exception if the org ID can't be found; just
handle that situation the same way as if a non-member were sending the
GraphQL query, and return only public projects just to be safe.

The createGuestUserByAdmin function in user.ts is typed as returning a
LexAuthUser, which means that it needs the new `orgs` property in order
to pass the type test. So we need to query it from the GraphQL result.

This will allow org admins to see all details (including email
addresses) of users in the orgs they manage.

Not working yet due to type errors.

Now that orgs can own projects, and anyone can see the list of projects
that an org owns, non-project members will sometimes be clicking on
project links. Changing the project table to hide links if the viewer
doesn't have permission is complicated, so for now we'll go with the
simple expedient of showing a 404 page if the user clicks on a link to a
project he's not supposed to see. We'll change this later.

This reverts commit 349556c.

Going to take a different approach: create a new permission called
CanViewProject, and rename CanAccessProject to CanSyncProject.

We'll create a new CanViewProject permission for read-only access to the
project metadata without repo access.

This allows public projects to let anyone view them, but still requires
project membership in order to access the repository.

This will allow testing that people who are not members of an org can
only see projects that are truly public (isConfidential == false) and
not projects where isConfidential == null. In order words, testing that
we're not failing open for projects with unknown confidentiality.

This is needed so that OrgProjectsVisibilityMiddleware can actually see
the isConfidential value. If isConfidential is not included in the GQL
query then the middleware sees it as null and defaults to private, thus
hiding projects that would have been visible.

Also remove no-longer-needed comment at same time

We should move it to an appropriate location and share it.

…or the orgById query.

Still need to implement removing email addresses from members list, if
the query asked for them without proper permission.

Public projects have isConfidential *false*, not true.

The "editor" user is a member of the test org; this test wants a
non-member.

This proves that the test will catch this bug.

This proves that the test suite is now catching the bug.

Also include unit tests to prove that non-managers cannot see usernames.

The org members table doesn't need to show the "user is locked" or
"email not verified" icons; those can be left on the admin dashboard.
But we do want the org managers to be able to see members' usernames,
since there may very well be guest users in the org with usernames but
no email addresses, and org managers should be able to help them get
Send/Receive configuration set up properly.

Org page show shows the email/username column to org managers/admins,
because we have decided that they're allowed to see it and have
implemented GraphQL rules to that effect.

Org managers, like admins, should be able to see who created a guest
user's account. We expose this in the UserModal by adding createdBy to
the orgMemberById query.

We have that logic in PermissionService now, so let's use it.

We decided that people who aren't org members can still see the projects
that they themselves are a member of, which means the rule for projects
is the same for both members and non-members so the code gets simpler.

Now there's a single source of truth for the two middleware classes that
need to reference it.

The LoginAs method needs to be virtual so that it can be mocked when
non-integration tests are running, otherwise the mock will still try to
log in to a server that isn't there.