Forcing service resource detector prevents from using more static service instance id

Describe your environment
We have:

• NewRelic
• otel-collector-contrib
• monolith php app with manual instrumentation

As it was mentioned before (here and here) - paraphrasing - if we don't like usage of uuid as service id we can write our own resource detector. Change that was introduced in PR#1573 prevents us from doing so.

Why this is important?
We use NewRelic and they require some of the fields to have low cardinality and one of hose fields is service.instance.id.

Please either move those two lines above foreach from line 41 - so those are always added BUT there is a way to override those fields (less desirable because it will create objects just to overwrite them) - or restore previous behavior where we could just not list them in OTEL_PHP_DETECTORS env variable and replace with custom implementation (less resource usage).

This is breaking our instrumentation and we had to rollback to previous versions.

Steps to reproduce
Send any span or metric

What is the expected behavior?
Be able to override value service.instance.id using resource detector.

What is the actual behavior?
Because service is added at the end and detectors are processed from top to bottom there is no way to override value of that field.

Additional context
In my opinion otel spec is incorrect in description of this field and it is targeting only long running applications like java or .net that start once and handle thousands of requests without restart. In php world where everything lives in the request and it recreated this value should be stable.

Read PR#1573 and the resource detector code around line 41, then review how OTEL_PHP_DETECTORS controls detector ordering. Reproduce the issue by sending a span or metric with a custom detector, and verify that service.instance.id can be overridden without forcing the default detector.