Documentation of `shouldLoopInfinitely`, `expectedResponse`, `nextReconcile` and `rollbackRetriesLimit`

### What problem are you facing?
We are using the plugin a lot at this point and it's super helpful, thanks!

It would be really beneficial to have a breakdown of the logic dependencies between `shouldLoopInfinitely`, `expectedResponse`, `nextReconcile` and `rollbackRetriesLimit`. The code seems pretty stable so maybe this isn't a perishable contrib? I can't quite sort it and am concerned about missing changes between versions if that were to happen.

As it stands, [code such as this](https://github.com/crossplane-contrib/provider-http/blob/b88c35694d56b2a484f2806de15e0e8cf0cef273/internal/controller/disposablerequest/disposablerequest.go#L169-L176) explains a lot of what's happening, but then I read #42 and there are apparently more nuances.

My use case is to set a feature flag on an endpoint that may not be ready upon first try. The feature flag is protected by OAuth token with a very short refresh. As it stands, there needs to be two `DisposableRequest`s, one for the OAuth token and a second one for the feature flag.

This works, but I'd like both to stop iterating once the flag has been set. Is that possible?

The token renewal process would ideally be a direct dependency on the requests that use it. Maybe something like a `tokenRenewalRef` property in the request spec that multiple requests could use to renew a shared token. In that manner, the token renewal only runs on-demand.

```
apiVersion: http.crossplane.io/v1alpha2
kind: DisposableRequest
spec:
deletionPolicy: Orphan
forProvider:
method: POST
url: {{ printf "%s/auth/realms/master/protocol/openid-connect/token" $baseUrl }}
headers:
Content-Type:
- application/x-www-form-urlencoded
insecureSkipTLSVerify: true
shouldLoopInfinitely: true
nextReconcile: 30s
expectedResponse: '.statusCode >= 200 and .statusCode < 300'
body: "client_id=admin-cli&grant_type=password&username=admin&password=password"
secretInjectionConfigs:
- secretRef:
name: {{$id}}-secrets
namespace: default
keyMappings:
- responseJQ: .body.access_token
secretKey: keycloak_access_token
setOwnerReference: true
---
apiVersion: http.crossplane.io/v1alpha2
kind: DisposableRequest
spec:
deletionPolicy: Orphan
forProvider:
method: PUT
url: {{ printf "%s/auth/admin/realms/lightrun/identity-provider/instances/%s" $baseUrl $companyId }}
headers:
Authorization:
- 'Bearer {{`{{`}} {{$id}}-secrets:default:keycloak_access_token {{`}}`}}'
Content-Type:
- application/json
insecureSkipTLSVerify: true
shouldLoopInfinitely: false
expectedResponse: '.statusCode >= 200 and .statusCode < 300'
rollbackRetriesLimit: 888
```

Start by reading internal/controller/disposablerequest/disposablerequest.go, especially the referenced logic, and compare it with the nuances discussed in issue #42. Document how shouldLoopInfinitely, expectedResponse, nextReconcile, and rollbackRetriesLimit interact, including the stopping behavior shown by the example.

Written by the indexing model from the issue text.