(#940) Update release notes

(#940) Fix regression involving Email Processor and ".unknown" attachments

Include Dave D for review purposes

This updates a line which was added in the past day (#14194) to ensure that
the data is escaped.

Add in 5.13.1 release notes and increment version to 5.13.1

Fix REST on WordPress

Resolve dev/core#931 by not doing translation on the query if field e…

Resolve #931 by not doing translation on the query if field exists during the upgrade process

5.13.0 release notes

(flexmailer#29) civicrm/mailing/view - Use Mailing.preview API. Fix compatibility with Flexmailer.

Fix deprecation handling [intra-rc-follow up] on #13999]

A root cause of flexmailer#29 is that the flexmailer has to override
multiple parts of CiviMail.  Case in point: it overrides the
`civicrm/mailing/view` and forces it to generate content via
`Mailing.preview` API.  This is unfortunate because flexmailer's variant is
missing other features (regarding permissioning and contact IDs).

This revision makes it unnecessary for flexmailer to override
`civicrm/mailing/view`.

flexmailer#26 Fix Flexmailer handling of annonmous user access to view Mailings by porting handling of annon situation to api

Turns out we were one of the sites naughtily using the BAO directly who needed this handling
to work - but because we passed a number in quote it didn't - this fixes

CiviMail - Restore support for preview of "mailing"/"action" tokens via TokenProcessor/Flexmailer

The preceding commits revised the behavior of `{mailing.*}` and `{action.*}`
when previewed via `TokenProcessor` (so that they match the preview
logic in other cases).

This simply changes the spec to match.

dev/core#907 Fix Deprecation notice for PHP7.2 in bin/cli.class.php

See preceding commit for general description - this simply applies the same
concept for another set of tokens.

Overview
--------

When using `TokenProcessor` to generate a mailing (e.g.  as with Flexmailer/Mosaico), the action-tokens (e.g.
`{action.optOutUrl}`) are generated via `CRM_Mailing_ActionTokens`.  To properly generate them,
`CRM_Mailing_ActionTokens` relies on certain information (e.g.  mailing/job ID).  However, that information is no
longer available when performing a "Preview" -- leading to misbehavior in previews.  This patch allows Flexmailer to
restore parity for previewing those tokens.

Before (Pre-5.6)
----------------

* When a user begins composing a mailing, CiviMail creates a draft mailing with a concrete ID (e.g.  `mailing #123`).
* To preview the mailing, the UI calls `Mailing.preview` API with the ID of the mailing.
* Flexmailer/Mosaico generates the preview by calling `TokenProcessor` and therefore `CRM_Mailing_ActionTokens`.
* `CRM_Mailing_ActionTokens` has strictness checks. These pass because the ID is available.

Before (5.6-5.12)
----------------

As a performance enhancement, CiviCRM 5.6 (PR #12509; [mail#20](mail#20)) revised
the signature for `Mailing.preview` API to allow previews *without* having a specific mailing record/job/ID. Consequently:

* When a user begins composing a mailing, CiviMail creates a draft mailing with a concrete ID (e.g.  `mailing #123`).
* To preview the mailing, the UI calls `Mailing.preview` API ~~with~~ **without** the ID of the mailing.
* Flexmailer/Mosaico generates the preview by calling `TokenProcessor` and therefore `CRM_Mailing_ActionTokens`.
* `CRM_Mailing_ActionTokens` has strictness checks. These ~~pass~~ **fail** because the ID is ~~available~~ **unavailable**.

After
----------------

* When a user begins composing a mailing, CiviMail creates a draft mailing with a concrete ID (e.g.  `mailing #123`).
* To preview the mailing, the UI calls `Mailing.preview` API ~~with~~ **without** the ID of the mailing.
* Flexmailer/Mosaico generates the preview by calling `TokenProcessor` and therefore `CRM_Mailing_ActionTokens`.
* `CRM_Mailing_ActionTokens` has ~~strictness~~ **less strict** checks. These **pass** because the `context[schema]` hints that
  a mailing ID *will be available* when needed.