Potentially fixes: #9963

We have been using a boolean flag isRequestHandlerWrapped in the scope of instrumentServer to avoid instrumenting Remix build multiple times when an Express server adapter is manually instrumented too.

The reason behind that decision was that we could not be sure that the build object is the same, so looking for __sentry_original__ on the wrapped function was not reliable all the time.

While we still can't reproduce locally, #9963 showed that this strategy (hack) may not work all the time, so I tried to find an alternative reliable way to resolve this.

This PR introduces instrumentation for getLoadContext which is available in all Remix server adapters, and passes data to loader/action/requestHandlers, to supply information about in which context a wrapped loader / action / requestHandler is used.

We still run instrumentBuild inside Sentry.init for all Express / non-Express applications, but with this context, we can gauge the behaviour of instrumented functions, depending on which instrumentBuild they're invoked from.

So, with this PR we maintain two side-effect free flags:

• __sentry_express_wrapped__ from the instrumented getLoadContext
• manuallyInstrumented flag we pass to instrumentBuild function which can be invoked either from Sentry.init or wrapExpressCreateRequestHandler

Having those two, an instrumented loader / action / requestHandler will behave accordingly to avoid creating multiple transactions.

This approach can also be applied to injecting baggage and sentry-trace as mentioned in #9737 in a new PR, if this gets merged.

Additionally, this PR makes a slight change on the ordering of host lookup of RequestData, which I came across while testing this.

Still not sure if this fixes the exact problem mentioned in #9963, but regardless IMHO it feels like a better resolution for this problem. cc: @souredoutlook