fix: ScheduleMessage not returning scheduled_message_id (#1153)

I'd like to introduce the fix for `ScheduledMessage` API. Currently, it
doesn't return scheduled_message_id where this ID is needed for
cancelling the scheduled message. My change is the least intrusive I
could think of. It doesn't introduce any new field or adding new API.
Basically, this change should be backward compatible. It is based on the
fact that the API
[chat.postMessage](https://api.slack.com/methods/chat.postMessage#examples)
doesn't return `scheduled_message_id` and the API
[chat.scheduledMessage](https://api.slack.com/methods/chat.scheduleMessage#examples)
doesn't return either `message.ts` or `ts`. We just need to check the
presence of this field and determine the caller API based on that.

Existing code shouldn't break because the `timestamp` is always an empty
string for `ScheduledMessage` API.
Now it will return `scheduled_message_id` in place of `timestamp`. 
`SendMessage` should remain the same.

##### Pull Request Guidelines

These are recommendations for pull requests.
They are strictly guidelines to help manage expectations.

##### PR preparation
Run `make pr-prep` from the root of the repository to run formatting,
linting and tests.

##### Should this be an issue instead
- [ ] is it a convenience method? (no new functionality, streamlines
some use case)
- [ ] exposes a previously private type, const, method, etc.
- [ ] is it application specific (caching, retry logic, rate limiting,
etc)
- [ ] is it performance related.

##### API changes

Since API changes have to be maintained they undergo a more detailed
review and are more likely to require changes.

- no tests, if you're adding to the API include at least a single test
of the happy case.
- If you can accomplish your goal without changing the API, then do so.
- dependency changes. updates are okay. adding/removing need
justification.

###### Examples of API changes that do not meet guidelines:
- in library cache for users. caches are use case specific.
- Convenience methods for Sending Messages, update, post, ephemeral,
etc. consider opening an issue instead.

chat.go

@@ -116,13 +116,13 @@ func (api *Client) ScheduleMessage(channelID, postAt string, options ...MsgOptio
 // ScheduleMessageContext sends a message to a channel with a custom context.
 // Slack API docs: https://api.slack.com/methods/chat.scheduleMessage
 func (api *Client) ScheduleMessageContext(ctx context.Context, channelID, postAt string, options ...MsgOption) (string, string, error) {
-	respChannel, respTimestamp, _, err := api.SendMessageContext(
+	respChannel, scheduledMessageId, _, err := api.SendMessageContext(
 		ctx,
 		channelID,
 		MsgOptionSchedule(postAt),
 		MsgOptionCompose(options...),
 	)
-	return respChannel, respTimestamp, err
+	return respChannel, scheduledMessageId, err
 }
 
 // PostMessage sends a message to a channel.
@@ -214,7 +214,7 @@ func (api *Client) SendMessage(channel string, options ...MsgOption) (string, st
 
 // SendMessageContext more flexible method for configuring messages with a custom context.
 // Slack API docs: https://api.slack.com/methods/chat.postMessage
-func (api *Client) SendMessageContext(ctx context.Context, channelID string, options ...MsgOption) (_channel string, _timestamp string, _text string, err error) {
+func (api *Client) SendMessageContext(ctx context.Context, channelID string, options ...MsgOption) (_channel string, _timestampOrScheduledMessageId string, _text string, err error) {
 	var (
 		req      *http.Request
 		parser   func(*chatResponseFull) responseParser
@@ -238,7 +238,11 @@ func (api *Client) SendMessageContext(ctx context.Context, channelID string, opt
 		return "", "", "", err
 	}
 
-	return response.Channel, response.getMessageTimestamp(), response.Text, response.Err()
+	if response.ScheduledMessageID != "" {
+		return response.Channel, response.ScheduledMessageID, response.Text, response.Err()
+	} else {
+		return response.Channel, response.getMessageTimestamp(), response.Text, response.Err()
+	}
 }
 
 func redactToken(b []byte) []byte {