Add a document section about deferInitialization option when releasing v3.10

[seratch]

The pull request #1303 in v3.10 milestone will add a new option deferInitialization. We can add a corresponding document section for it when it's released.

---

This is great, thanks for tackling this @seratch !

Not sure if we should bundle the documentation for this feature in this PR, or a separate one, but I think before merging this PR we should at least write a draft of the docs for this support. In my experience, writing up the docs alongside (or even before) the code is written up can help clarify how to structure the code too. I am happy to help write the docs if you would find that helpful - let me know, I can try to create a draft!

Originally posted by @filmaj in #1303 (review)

[filmaj]

Thinking about where to add this documentation, I am not entirely sure. My initial thought is a new section under the 'Advanced Concepts' of the bolt-js docs - perhaps "Deferring initialization"? This would be a short section, similar perhaps to the Logging doc, describing 1) why someone would want to defer initialization, 2) how to do it and 3) what errors to expect if this is done incorrectly. Some ideas for copy for these sections:

1. Perhaps something along the lines of "When initializing your Bolt app with the App constructor, an authentication test call is automatically made to the Slack backend to verify your tokens. In certain situations it may be desirable to more carefully control the timing of these calls. Bolt offers a way to defer initialization via the deferInitialization option, which places responsibility for fully initializing the Bolt app into your hands as the app developer." ?
2. The right side of the docs layout would show a sample section of an app being constructed with the deferInitialization option, then further down in the code explicit invocation of the init() and then start() methods.
3. Call out the fact that if start() is called before init(), an exception will be thrown.

Thoughts/opinions/comments?

Oh, and of course updating any reference-style documentation would be in order, too.

[seratch]

@filmaj All look good to me!

Oh, and of course updating any reference-style documentation would be in order, too.

Yes, specifically, https://slack.dev/bolt-js/reference#app-options should be updated too.

[srajiang]

@filmaj How about instead of:

When initializing your Bolt app with the App constructor, an authentication test call is automatically made to the Slack backend to verify your tokens.

Something along the lines of:

Bolt offers a way to defer full initialization via the deferInitialization option and to call the equivalent App#init() in your code, putting more control over asynchronous events required for initialization into your hands as the developer.

[filmaj]

Thanks for the comments and suggestions! PR is up here, if you have further comments or reviews let's move it to the PR: #1308