fix(VToolbar): v-btn location in and outside of prepend/append elements

[johnleider]

Description

Adjust v-btn location depending upon it's location in v-toolbar.

Motivation and Context

Visual consistency

How Has This Been Tested?

visually

Markup:

<template>
  <v-app>
    <v-main>
      <div>
        <v-container>
          <v-toolbar>
            <template #prepend>
              <v-app-bar-nav-icon />
            </template>

            <v-toolbar-title class="text-h6">
              Messages
            </v-toolbar-title>

            <template #append>
              <v-btn icon="mdi-dots-vertical" />
            </template>
          </v-toolbar>
          <br>
          <br>
          <v-toolbar density="compact">
            <v-app-bar-nav-icon />

            <v-toolbar-title class="text-h6">
              Messages
            </v-toolbar-title>

            <template #append>
              <v-btn icon="mdi-dots-vertical" />
            </template>
          </v-toolbar>
        </v-container>
      </div>
    </v-main>
  </v-app>
</template>

<script>
  export default {
    data: () => ({
      messages: [
        {
          from: 'You',
          message: `Sure, I'll see you later.`,
          time: '10:42am',
          color: 'deep-purple lighten-1',
        },
        {
          from: 'John Doe',
          message: 'Yeah, sure. Does 1:00pm work?',
          time: '10:37am',
          color: 'green',
        },
        {
          from: 'You',
          message: 'Did you still want to grab lunch today?',
          time: '9:47am',
          color: 'deep-purple lighten-1',
        },
      ],
    }),
  }
</script>

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Improvement/refactoring (non-breaking change that doesn't add any features but makes things better)

Checklist:

• The PR title is no longer than 64 characters.
• The PR is submitted to the correct branch (master for bug fixes and documentation updates, dev for new features and backwards compatible changes and next for non-backwards compatible changes).
• My code follows the code style of this project.
• I've added relevant changes to the documentation (applies to new features and breaking changes in core library)