Our code currently uses the `IConstructorSignature` types in a two main ways:

- As argument types in functions that take a service constructor.
- As return types or property types when we expose a service constructor in the API

This first usage is not valid with strict function types. The reason is that the `IConstructorSignature` types takes a rest array of `...services: BrandedService[]` , while the concrete constructors you pass in use actual services. With strict function types, you cannot convert the concrete constructor type to an `IConstructorSignature` because this would drop important type information that the implementation needs. As an example

```ts
class Foo {
    constructor(@ILogService service: ILogService) {}
}

registerFoo(Foo);

// The type of `ctor` inlines `IConstructorSignature0`
function registerFoo(ctor: { new(....serivces: BrandedService[]): Foo}) {
   // When registerFoo(Foo) is called, the implementation here would need to know that
   // ctor needs to be invoked with exactly one `ILogService`. However the type of `IConstructorSignature0`
   // does not express this. Strict function types therefore disallows this conversion
}
```

To fix this, I have converted a few places were we were taking `IConstructorSignature` arguments so that they preserve the full type of the constructor. This fixed over half of our 900 strict function type errors. Unfortunatly I can not figure out a more elegant way to express this besides inlining the types

However, even after this change, we still need to figure out how to deal with:

- Places in the code where `IConstructorSignature` is exposed as a return type or object property
- How to deal with all of our descriptor types (such as `SyncActionDescriptor`)

Prefer using these predicates as they are shorter and make the code easier to understand

#78168

Also changes processService to not modify its input actions, which seems like unexpected behavior

There were a few interface methods that were only referenced by their implementation and never actually called. Remove these

#70020

Replaces many loops of the form:

```js
for (let i = 0; i < elements.length; ++i) {
    const i = elements[i];
   ...
}
```

with:

```js
for (const element of elements) {
    ...
}
```

Mix of a horrible regex based find/replace and manual touch ups

We compile using the alwaysStrict flag so these directives are not needed

This part removes most `use strict` directives that are right after the file header

- avoid public modifier
- use Disposable where applicable
- fix some event handler leaks
- clean up some TODO@ben

This reverts commit 27256832 which turns out did not break the import of vs/nls

This reverts commit 7de696a2.

Seems to have broken loading vs/nls in at least one case in insiders

Don't use this import form in places where it is not needed. This prevents us from correctly detecting duplicate imports