Adjust releasing tools to work with monorepo

[mlewand]

Subissue of #6466.

Requires: https://github.com/ckeditor/ckeditor5-dev/issues/608.

[pomek]

A question: how to specify new versions of the packages? Now they are gathered from changelogs. If we will have a single changelog, it can be a little harder.

Or maybe not but we don't know how the changelog will look.

[mlewand]

Estimated blindly at 5 points, we still need to clarify our requirements.

[mlewand]

I think we should embrace the chance to reshape the changelog. I would see following changes:

• We should drop long introductions in favor of (possibly) short and concise feature/change list.
• The main changelog should contain all notable changes.
• Longer text should be extracted, and available as a link for further reading only. I'm thinking here about migration instructions (see build-decoupled-document in the example below).
• Changelog entries that are related to a particular package should be prefixed with the package name.
• Changelog should contain a link to all (including ignored and minor) issues closed in a given release.

I agree with this quote from keep a changelog initiative:

Changelogs are for humans, not machines.

So legibility is important and we should avoid redundant text, or script-friendly lists.

A proposal is format like the following:

## 17.0.0

### Collaboration features

The CKEditor 5 Collaboration features changelog can be found here: <https://ckeditor.com/collaboration/changelog>.

### Major breaking changes

* [build-decoupled-document] The document editor build does not contain the highlight feature is replaced with the font color and font background color features. (link to migration instructions, e.g. GH comment permalink)
* [watchdog] The `Watchdog` class was renamed to `EditorWatchdog` and is available in `src/editorwatchdog.js`.
* [watchdog] The `EditorWatchdog.for()` method was removed in favor of the constructor.
* [watchdog] Now the `EditorWatchdog` constructor accepts the editor instance as the first argument and the watchdog configuration as the second argument. The `EditorWatchdog` editor creator now defaults to `( sourceElementOrData, config ) => Editor.create( sourceElementOrData, config )`.

### Minor breaking changes

* (...)

### Features

* [special-characters] Introduced new special characters feature. Closes ckeditor/ckeditor5#1110.
* [table] Implemented the table and table cell properties forms. Closes ckeditor/ckeditor5#3287.
* [core] Introduced [editor context API](https://ckeditor.com/docs/ckeditor5/latest/api/module_core_context-Context.html).
* [watchdog] Introduced `ContextWatchdog` which is a watchdog for `Context`. Closes [ckeditor/ckeditor5#6079](https://github.com/ckeditor/ckeditor5/issues/6079).    

### Fixes

* [table] Fixed a bug with spellchecking or pasting via the context menu into a table cell crashing the editor. Closes ckeditor/ckeditor5#6062. 

### Other

* [table] Implemented lazy loading for the table dropdown. This will reduce editor initialization time. Closes ckeditor/ckeditor5#6193.

You can find [all the fixed issues in v18.0.0 issues](https://github.com/ckeditor/ckeditor5/issues?q=is%3Aissue+milestone%3A%22iteration+29%22+is%3Aclosed) on our GitHub repository.

In case there are changes that affect (almost) all packages we could use [general] which would make sense to be placed at the top of its section. A good candidate would be accessibility or performance (in tehe example above I could aggregate table perf improvements with couple of other that were in this release).

Our current approach of picking initial changelog values from commit messages seem to work fine.

[pomek]

There is a problem with builds.

As for now, we are using npm prehooks for building fresh versions. The release tool at some point calls:

exec( `npm version ${ releaseDetails.version } --message "Release: v${ releaseDetails.version }. [skip ci]"` );

for every repository (in proper directory).

It means, the preversion hook was called before npm version and postversion (if defined) was called after.

After switching to one repository, calling this command will produce 5 the same commits. The preversion hook looks like:

{
  "preversion": "npm run build; if [ -n \"$(git status src/ckeditor.js build/ --porcelain)\" ]; then git add -u src/ckeditor.js build/ && git commit -m 'Internal: Build.'; fi"
}

Instead, we could remove "committing option" from the hooks (just call the build command) and commit everything after bumping version

[mlewand]

Yup, it make sense to make just one commit. So preversion hook should not handle committing, instead this should be handled by parent builder script.

[pomek]

On the i/606 branch I've just pushed the adjusted version of release tools.

Release tools handle monorepo now. They also work with single repo (integrations).