Add release helper script (#64)

This commit adds a release helper script, amongst other workflow improvements.

See `README.md` for instructions, and `_tools/release.sh` for the script itself.

This script:

1. sanity-checks the various version tags;
2. triggers a Plugin build;
3. flags the new version as pre-release;
4. tags the version in Git;
5. creates a local working copy of the SVN repo;
6. copies the new release to the local `trunk/` (whilst keeping the ‘Stable Tag’ field in `readme.txt` pointing to the previous stable version);
7. copies the commit message from the changelog in `readme.txt`; and
8. (if a flag is set) commits the changes to the remote `trunk/`.

Pushing out a new release must still be done manually, once `trunk/` is tested and working. To do so, check out a local copy of `trunk/` and:

1. update the ‘Stable Tag’ field in `trunk/readme.txt` to the new version;
2. update the ‘Version’ field in the comment header of `trunk/footnotes.php` to the new version;
3. remove the ‘p’ from the end of the ‘version’ tag in the `getInfo()` function at the bottom of `js/wsiwyg-editor.js`; 
4. copy a new tag for the release from `trunk/` (`svn cp trunk tags/<version number>`); and
5. commit your changes (`svn ci -m "Release version <version number>"`).

The WP Plugin Directory will automatically parse the ‘Stable Tag’ field in `trunk/readme.txt`, and inform users that a new version is available.

At various stages user input is required to validate information. This is not ready for automation with GitHub Actions, but is a useful step on the way — see [this piece](https://blog.danslimmon.com/2019/07/15/do-nothing-scripting-the-key-to-gradual-automation/) for more info.

Unless a `-c` flag is passed (e.g., by running `composer run release:commit`) no changes will take place on the remote SVN repo. If you want to test this out on a branch other than `main`, uncomment lines 31 & 52 of the script.

Version checking enforces the versioning rules stated [here](https://github.com/markcheret/footnotes/wiki/Versioning).

**NB: I have not tested the `-c` mode yet, as I wanted people will more familiarity with the SVN to have a look at it before I risked making any changes and blowing everything up.**

Co-authored-by: pewgeuges <73141620+pewgeuges@users.noreply.github.com>

README.md

@@ -4,7 +4,7 @@
 
 ## Description
 
-Featured on [wpmudev](http://premium.wpmudev.org/blog/12-surprisingly-useful-wordpress-plugins-you-dont-know-about/) --- cheers for the review, folks!
+Featured on [wpmudev](http://premium.wpmudev.org/blog/12-surprisingly-useful-wordpress-plugins-you-dont-know-about/) — cheers for the review, folks!
 
 **footnotes** aims to be the all-in-one solution for displaying an automatically generated list of references on your Page or Post. The Plugin ships with a set of defaults while also empowering you to control how your footnotes are being displayed.
 
@@ -14,21 +14,19 @@ Featured on [wpmudev](http://premium.wpmudev.org/blog/12-surprisingly-useful-wor
 
 1. Read the contributing guidelines
 1. Clone this repository (`git clone git@github.com:markcheret/footnotes.git`)
-  - We recommend that you use [VVV](https://varyingvagrantvagrants.org/) for your development environment
+    - We recommend that you use [VVV](https://varyingvagrantvagrants.org/) for your local testing environment
 1. Install [Composer](https://getcomposer.org/download/), if you don't have it already
 1. Install dependencies (`composer install`)
-1. Create a new branch from `main` (`git checkout -b <your-descriptive-branch-name>`)
-1. When you're finished, commit your changes to the remote version of your branch
-   and submit a [pull request](https://github.com/markcheret/footnotes/pulls).
+    - You will have to install `php-mbstring` manually if you do not already have it.
 
-## Checking WP Coding Standard Compliance
+## Code Formatting
 
-1. Run PHP_CodeSniffer on the file(s) you want to check (`./vendor/bin/phpcs --standard="WordPress" --colors --encoding=utf-8 -n -p <file(s)>`)
-1. (If applicable) run the PHP Code Beautifier and Formatter to attempt to automatically fix any errors (`./vendor/bin/phpcbf --standard="WordPress" --encoding=utf-8 -p <file(s)>`)
-  - Add the `-n` flag to ignore warnings (i.e., show only errors)
-  - Add the `-s` flag to show sniff codes (used for disabling errors in the code with `phpcs disable:<sniff code>` — MAKE SURE THAT YOU HAVE `phpcs enable` AT THE EARLIEST POINT POSSIBLE, and provide a justification for disabling the sniff code)
-  - You can run either across the entire project by adding the argument `--ignore=*/vendor/*` and targetting the file `./**/*.php`
-    - You may have to enable double-wildcards in your console first (`shopt -s globstar`)
+1. Run `composer run lint-php` to lint all PHP files
+1. Run `composer run lint-php:fix` to attempt to automatically fix errors and warnings
+
+## Releasing
+
+1. Run `composer run release`
 
 ## Building
 
@@ -44,8 +42,7 @@ Featured on [wpmudev](http://premium.wpmudev.org/blog/12-surprisingly-useful-wor
 
 ## Updating Documentation
 
-1. Install [phpDocumentor](https://phpdoc.org/)
-1. Run it (`phpDocumentor -d . -t docs`)
+1. Run `composer run docs`
 
 ## Testing
 
@@ -66,8 +63,8 @@ Unit tests are TODO.
 
 These are a few examples of possible ways to delimit footnotes:
 
-1. Your awesome text((with an awesome footnote))
-2. Your awesome text[ref]with an awesome footnote[/ref]
+1. Your awesome text`((`with an awesome footnote`))`
+2. Your awesome text`[ref]`with an awesome footnote`[/ref]`
 3. Your awesome text`<fn>`with an awesome footnote`</fn>`
 4. Your awesome text`custom-shortcode`with an awesome footnote`custom-shortcode`