API and architecture of PlatformContext

This issue is used to discuss the API and architecture of the platform context that is today defined by the `PlatformContext` interface.

The main goal of the `PlatformContext` interface is to provide all base services within the scope of a platform instance. Based on that all services that are provided by a `PlatformContext` instance must not have a lifetime that does not match to then lifetime of the platform: Either a service has the same lifetime or is a singleton.

The `PlatformContext` interface provides getter for all the different services:

```
public interface PlatformContext {

Configuration getConfiguration();

Metrics getMetrics();
}
```

While the lifecycle of a `PlatformContext` instance is bound to the lifecycle of a `Platform` instance it must not implement interfaces like `Startable` or `Stoppable`. Next to that no public service AI that is exposed by the `PlatformContext` must implement an interface to interact with the lifecycle (today we still have that and should fix it in future: `Metrics` should not depend `Startable` but `MetricsImpl` can do that).

The `PlatformContext` API should be based on the service API that is defined [here](https://github.com/hashgraph/hedera-services/blob/develop/platform-sdk/docs/base/service-architecture/service-architecture.md). Based on that we have the following factory interface next to the `PlatformContext` interface:

```
public interface PlatformFactory {

PlatformContext create(final Configuration config);

static PlatformFactory getInstance() {
return PlatformFactoryImpl.getInstance();
}
}
```

For both interfaces the implementation is defined as private api and should not be used. The implementation of the factory will look like that:

```
public class PlatformFactoryImpl implements PlatformFactory {

private final static class InstanceHolder {
private final static PlatformFactory INSTANCE = new PlatformFactoryImpl();
}

public PlatformContext create(final Configuration config) {
return new PlatformContextImpl(config, new MetricsImpl(config));
}

public static PlatformFactory getInstance() {
return InstanceHolder.INSTANCE;
}
}
```

Since implementations of services that are part of the context can have a lifecycle that is bound to the platform lifecycle the idea is to cover that lifecycle in the private `PlatformContext` implementation:

```
public class PlatformContextImpl implements PlatformContext, Startable, Stoppable {

private final Configuration config;

private final Metrics metrics;

private final Set stoppables = new HashSet();

public PlatformContextImpl(final Configuration config, Metrics metrics) {
this.config = config;
this.metrics = metrics;

if(config instanceOf Configuration stoppable) {
stoppables.add(stoppable)
}
if(metrics instanceOf Stoppable stoppable) {
stoppables.add(stoppable)
}
}

public Configuration getConfiguration(){return config;}

public Metrics getMetrics() {return metrics;}

public void stop(){stoppables.forEach(s -> s.stop());}

public void start() {SIMILAR_TO_STOP}
}
```
(We discussed several approaches how the start/stop functionality can be hidden from public api and that is currently the best approach we found so far).

A `PlatformContextImpl` will started automatically when the platform instance starts.

Start with platform-sdk/docs/base/service-architecture/service-architecture.md, then review the PlatformContext and PlatformFactory interfaces described in this issue. The issue is an architecture discussion rather than a scoped implementation task, so a concrete set of API changes and acceptance criteria would need to be established before work can be considered done.

Written by the indexing model from the issue text.