Add endpoints for calls.* apis and Type: call in blockkit

[winston-stripe]

Implement the API methods for the Calls API in Slack https://api.slack.com/apis/calls

Implemented methods

• calls.add - Indicate a new call has been started
• calls.end - Indicate to slack that the call has ended
• calls.info - Get information about an ongoing slack call object
• calls.update - update call information
• calls.participants.add
• calls.participants.remove

Additionally, I've added the minimal version of Block{Type: "call", CallID: string} which slack recommends/requires be posted back to the channel https://api.slack.com/apis/calls#post_to_channel.

All implemented functionality is publicly documented. There appear to be additional attributes on the type: call block, however those appear to be internal values for slack's rendering, so I have left them out. See this gist for specific responses https://gist.github.com/winston-stripe/0cac608bd63b42d73a352be53577f7fd

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.

[winston-stripe]

Oddly, I have no idea why the lint step is failing. Downloaded and ran golangci-lint run locally and everything ran without a hitch. Maybe some weird bad caching or some unexpected actions interaction? Fwiw, when looking through their docs, I did notice that

v3.0.0+ requires explicit setup-go installation step prior to using this action: uses: actions/setup-go@v3

Still no idea otherwise esp since master is passing, i'm fully based off of master, and all failing files are other ones I didn't touch here 😕.

[winston-stripe]

Thanks @kanata2 for fixing the repo's linting check in #1194! rebased off master and everything is passing now

[winston-stripe]

bump: @kanata2 is it possible to get a 👀 on this?