Description of Pull Request:

This is a minor but useful change to make the default slot (modal body) into a scoped slot. As per the blog post for the Vue 2.6 release, in the future all slots will be scoped slots anyway:

In 3.0, there will no longer be the distinction between scoped vs. non-scoped slots

In this PR the only scoped prop that I exposed was visible, which is whether the modal is visible or not. This is very useful because it makes it so you can easily mount/unmount modal content on visibility. This removes the need to worry about reseting components when a modal is opened again, which can be annoying when composing the content of components, some of which may not have an easy way to reset their state. From the blog post, there's also a small performance improvement using scoped slots, so that comes along for free as well.

Example of how this works with the scoped slot:

<b-modal>
  <template slot-scope="{ visible }">
    <MyComponent v-if="visible" />
  </template>
</b-modal>

This ensures MyComponent is unmounted and mounted any time the modal is shown, resulting in fresh state, which is my desired outcome.

PR checklist:

What kind of change does this PR introduce? (check at least one)

• Bugfix
• Feature
• Enhancement to an existing feature
• ARIA accessibility
• Documentation update
• Other, please describe:

Does this PR introduce a breaking change? (check one)

• Yes
• No

If yes, please describe the impact:

The PR fulfills these requirements:

• It's submitted to the dev branch, not the master branch
• When resolving a specific issue, it's referenced in the PR's title (i.e.
  fixes #xxxx[,#xxxx], where "xxxx" is the issue number)
• The PR should address only one issue or feature. If adding multiple features or fixing a bug
  and adding a new feature, break them into separate PRs if at all possible.
• PR titles should following the
  Conventional Commits naming convention (i.e.
  "fix(alert): not alerting during SSR render", "docs(badge): Updated pill examples, fix typos",
  "chore: fix typo in docs", etc). This is very important, as the CHANGELOG is generated
  from these messages.

If new features/enhancement/fixes are added or changed:

• Includes documentation updates (including updating the component's package.json for slot and
  event changes)
• New/updated tests are included and passing (if required)
• Existing test suites are passing
• The changes have not impacted the functionality of other components or directives
• ARIA Accessibility has been taken into consideration (does it affect screen reader users or
  keyboard only users? clickable items should be in the tab index, etc)

If adding a new feature, or changing the functionality of an existing feature, the PR's
description above includes:

• A convincing reason for adding this feature (to avoid wasting your time, it's best to open a
  suggestion issue first and wait for approval before working on it)