Documentation improvements.

I think it's a better to make these example uniform, it's really confusing.

semantic-release/gitlab (this project)

{
  "plugins": [
    "@semantic-release/commit-analyzer",
    "@semantic-release/release-notes-generator",
    ["@semantic-release/gitlab", {
      "gitlabUrl": "https://custom.gitlab.com",
      "assets": [
        {"path": "dist/asset.min.css", "label": "CSS distribution"},
        {"path": "dist/asset.min.js", "label": "JS distribution"}
      ]
    }],
  ]
}

1. It's not clear from the above how to publish an angular project, which builds into dist hand has many "assets". npm pack just needs to be told to the dist/ directory that contains the package.json, for example npm pack dist/my-workspace/my-lib. How do we package an angular project with Semantic-Release gitlab like above?
2. You post a gitlabUrl in there. It's not clear why I would ever want that. That can be supported by the package.json. Why would I want it here. For simplicity I would remove it.

GitLab wiki,

The following is from the GitLab wiki,

{
  "branches": ["master"],
  "plugins": [
    "@semantic-release/commit-analyzer",
    "@semantic-release/release-notes-generator",
    "@semantic-release/gitlab",
    "@semantic-release/npm",
    [
      "@semantic-release/git",
      {
        "assets": ["package.json"],
        "message": "chore(release): ${nextRelease.version} [skip ci]\n\n${nextRelease.notes}"
      }
    ]
  ]
}

1. Note this has branches That seems to be required. If it is this project should probably also contain it.

Start with the two configuration examples in the issue and compare them with the linked GitLab wiki example. Clarify how an Angular project with a dist package is packaged, explain or remove the gitlabUrl example, and establish whether branches belongs in the project example. Done means the documentation presents uniform, unambiguous configurations and answers these questions.