Clarify distinction between base & admin system test drivers

We'd like to refactor the system test code to make it clearer why there are two separate SystemTestDrivers objects that are used.

#### The two drivers

There's SystemTestDeploymentContext.drivers, which comes through to SleeperDsl.baseDrivers. There's also DeployedSleeperInstance.instanceAdminDrivers. In the places where these are used, it's not always clear which is which, and it's not easy to find a single place that clarifies the distinction between them.

You can find out what the admin drivers are by looking in DeployedSleeperInstance.loadOrDeployAtFirstConnect, where it uses AssumeAdminRoleDriver to assume the instance admin role, and create a new set of drivers in DeployedSleeperInstance.instanceAdminDrivers.

By contrast, the base drivers are set when the SystemTestDeploymentContext is first created, e.g. in AwsSleeperSystemTestExtension.

#### Intended use of instance admin role

We use the instance admin role whenever we can in order to exercise it in tests, and in order to move towards a situation where we have all the relevant roles in the system specified to the point where we no longer need to use a permissive admin role anywhere.

#### Changes

One approach to this might be to refactor how the instance admin drivers are retrieved in the DSL classes, e.g. in SleeperDsl. It should be clear that this might cause a problem with permissions, and you should only use the instance admin drivers if the instance admin role has the permissions you need.

Start with SleeperDsl, SystemTestDeploymentContext.drivers, and DeployedSleeperInstance.loadOrDeployAtFirstConnect, then compare how baseDrivers and instanceAdminDrivers are retrieved. Trace AwsSleeperSystemTestExtension to see where base drivers are created. Done means the two driver sets have a clear distinction in the DSL and permissions are preserved by using instance admin drivers only where their role allows it.

Written by the indexing model from the issue text.