Allow `PUT /organizations/{orgId}/monitors/{monitorId}/checkin/{checin_id}/` to create, not just update

We should allow for monitor checkins to be provided a checkin ID on creation.

This provides better ergonomics from the client side since the client now no longer needs to parse the response json just to get the checkin ID to use for updates.

This could look like

```bash
local checkin_id=$(uuidgen)

curl -X POST \
"https://example-org.sentry.io/api/0/monitors/my-monitor/checkins/" \
--header 'Authorization: DSN https://examplePublicKey@o0.ingest.sentry.io/0' \
--header 'Content-Type: application/json' \
--data-raw '{"id": "${checkin_id}", "status": "in_progress"}'

# Run my cron job

curl -X PUT \
"https://example-org.sentry.io/api/0/monitors/my-monitor/checkins/${checkin_id}/" \
--header 'Authorization: DSN https://examplePublicKey@o0.ingest.sentry.io/0' \
--header 'Content-Type: application/json' \
--data-raw '{"status": "ok"}'
```

We could also allow for `PUT` to be idempotent and also create a checkin when the checkin doesn't exist.

```bash
local checkin_id=$(uuidgen)

# Creates a checkin
curl -X PUT \
"https://example-org.sentry.io/api/0/monitors/my-monitor/checkins/${checkin_id}/" \
--header 'Authorization: DSN https://examplePublicKey@o0.ingest.sentry.io/0' \
--header 'Content-Type: application/json' \
--data-raw '{"status": "in_progress"}'

# Run my cron job

# Marks a checkin as completed
curl -X PUT \
"https://example-org.sentry.io/api/0/monitors/my-monitor/checkins/${checkin_id}/" \
--header 'Authorization: DSN https://examplePublicKey@o0.ingest.sentry.io/0' \
--header 'Content-Type: application/json' \
--data-raw '{"status": "ok"}'
```

## Alternatives

### `Accept: plain/text`

Instead of returning JSON from new checkins, we could allow `Accept: plain/text` to get back the checkin ID to make it easy to use from bash scripts

This could look like this then

```bash
local checkin_id=$(curl -X POST \
"https://example-org.sentry.io/api/0/monitors/my-monitor/checkins/" \
--silent \
--header 'Authorization: DSN https://examplePublicKey@o0.ingest.sentry.io/0' \
--header 'Content-Type: application/json' \
--header 'Accept: plain/text' \
--data-raw '{"status": "in_progress"}')

# Run my cron job

curl -X PUT \
"https://example-org.sentry.io/api/0/monitors/my-monitor/checkins/${checkin_id}/" \
--header 'Authorization: DSN https://examplePublicKey@o0.ingest.sentry.io/0' \
--header 'Content-Type: application/json' \
--data-raw '{"status": "ok"}'
```

#### Downsides of this approach

That's a lot more headers to pass, along with the silent option.

### Using the existing `latest` checkin ID

We support a `latest` checkin_id, which we don't really expose anywhere afaik

```bash
curl -X POST \
"https://example-org.sentry.io/api/0/monitors/my-monitor/checkins/" \
--header 'Authorization: DSN https://examplePublicKey@o0.ingest.sentry.io/0' \
--header 'Content-Type: application/json' \
--data-raw '{"status": "in_progress"}')

# Run my cron job

curl -X PUT \
"https://example-org.sentry.io/api/0/monitors/my-monitor/checkins/latest/" \
--header 'Authorization: DSN https://examplePublicKey@o0.ingest.sentry.io/0' \
--header 'Content-Type: application/json' \
--data-raw '{"status": "ok"}'
```
#### Downsides of this approach

You better be damn sure that you won't have overlapping monitor runs, otherwise you'll end up in a world of confusing debugging here.