assets option is ambiguous with git plugin assets option

Both the git plugin and github plugin have a configuration option named assets. When building out a shareable configuration, It is preferable to omit configuration inline with the plugin and define as much as possible in the top level of the release config so they can be overridden when the configuration is extended.

// my-release-config/index.js
module.exports = {
  npmPublish: false,
  releaseRules: [...],
  assets: ['package.json', '*.md', '!**/node_modules/**'],  // <---- assets
  changelogTitle: '## Changelog',
  plugins: [
    ['@semantic-release/commit-analyzer', null],
    ['@semantic-release/release-notes-generator', null],
    ['@semantic-release/changelog', null]
    ['@semantic-release/npm', null],
    ['@semantic-release/git', null],
    ['@semantic-release/exec', null],
    ['@semantic-release/github', null]
  ]
}

This works rather well except when you use the git and github plugins together - the assets configuration is ambiguous meaning. In the above example, All .md files will be included in both the release commit, and the files attached to the github release. if the value needs to be different between the two plugins, you have to define the plugin configuration inline, which makes it difficult to change

// my-release-config/index.js
module.exports = {
  npmPublish: false,
  releaseRules: [...],
  changelogTitle: '## Changelog',
  plugins: [
    ['@semantic-release/commit-analyzer', null],
    ['@semantic-release/release-notes-generator', null],
    ['@semantic-release/changelog', null]
    ['@semantic-release/npm', null],
    ['@semantic-release/git', {
      assets: ['package.json', '*.md', '!**/node_modules/**'] // <---- assets
    }]
    ['@semantic-release/exec', null],
    ['@semantic-release/github', {
       assets: ['dist/*.tgz', 'coverage/*.json']              // <---- assets
    }]
  ]
}

This allows them to be different, But now you cannot really over ride these values individually with out modifying them both, or changing them in the actualy config package being exteded. Which mean people have to re-define the entire plugin change and re-create most of the default configuration shipped with the shared config. Which mostly defeats the purpose.

Ideally, these settings should be named differently to disambiguate them - gitCommitAssets and githubReleaseAssets.
Something to this effect. It could initially be alternate value to allow the existing assets value to work if defined like it currently does.

Start by tracing how the git and github plugins resolve the shared top-level assets option and how plugin-specific options override it. Review the existing configuration and compatibility behavior before deciding how distinct names should work. Done means git commit assets and GitHub release assets can be configured independently while existing assets configurations continue to work.