Add Change record to @deprecated for install_ensure_config_directory()

Hey @eheller, @see have been added to install_ensure_config_directory. I confirm that no other @deprecated without @see is left in install.inc

I'm setting to RTBC. Thanks All

#patch 2 doesn't seems to follow depreciation policy.

#7: This issue is very limited in scope and is attempting to work on only some parts of deprecation.

+++ b/core/includes/install.inc
@@ -530,6 +530,8 @@ function drupal_install_config_directories() {
+ * @see https://www.drupal.org/node/2501187

git log -L520,540:core/includes/install.inc reveals that the @deprecation was added in #2466197: Staging directory should not have to be writeable., which does not have a change record.

So we should add #2466197: Staging directory should not have to be writeable. to the list of related issues for change record https://www.drupal.org/node/2501187

Restarting the test of #2 since it was never tested.

Added the issue to the change record and since the test on #2 passed I'm moving this to "Needs review".

Looks fine -> RTBC.

I'm at drupalcon Vienna and will try to add a @see for the deprecated install_ensure_config_directory() function
oeps. It's done already. Sorry.

Added 8.5.x test to #2, to make sure it all works.

Test agains 8.5.x passed as well.

According to https://www.drupal.org/core/deprecation we should also be adding an @trigger_error() to install_ensure_config_directory() - but we can't just do that because this method is used in \Drupal\simpletest\KernelTestBase::prepareConfigDirectories(). We need a follow-up issue to complete the deprecation of this method by removing the usages (just inlining the functionality into KernelTestBase::prepareConfigDirectories()) and to add the @trigger_error() call.

I've created #2914033: Complete deprecation of install_ensure_config_directory()

Committed/pushed to 8.5.x and cherry-picked to 8.4.x. Thanks!

Now we get on with #2914033: Complete deprecation of install_ensure_config_directory() - reviews appreciated.

Removing parent issue per conversation with @xjm at Drupalcon Nashville Mentored Sprint prep. Her recommendation to do so was based on a few points that made sense to all of us in the discussion, namely:
- so many child issues makes this parent unwieldy
- search filters will allow people needing to refind closed children