Add file post-processing to PHP generators

[wing328]

PR checklist

• Read the contribution guidelines.
• Ran the shell script under ./bin/ to update Petstore sample so that CIs can verify the change. (For instance, only need to run ./bin/{LANG}-petstore.sh and ./bin/security/{LANG}-petstore.sh if updating the {LANG} (e.g. php, ruby, python, etc) code generator or {LANG} client's mustache templates). Windows batch files can be found in .\bin\windows\.
• Filed the PR against the correct branch: master, 3.4.x, 4.0.x. Default: master.
• Copied the technical committee to review the pull request if your PR is targeting a particular programming language.

Description of the PR

Add file post-processing to PHP generators (e.g. export PHP_POST_PROCESS_FILE="/usr/local/bin/prettier --write" with --enable-post-process-file using CLI)
fcbb0f5#diff-3a3b8cc18e5f25dde7d39f027bf19ee4 shows the auto-format code done by ktlint

cc @jebentier (2017/07) @dkarlovi (2017/07) @mandrean (2017/08) @jfastnacht (2017/09) @ackintosh (2017/09) @ybelenko (2018/07)

[ybelenko]

@wing328 Can you explain use cases a bit?

As I've said before, usually all test/lint/format scripts are defined in composer.json in a manner:

{
  "scripts": {
    "test": [
      "@phplint",
      "@test-apis",
      "@test-models",
      "@phpcs"
    ],
    "test-apis": "phpunit --testsuite Apis",
    "test-models": "phpunit --testsuite Models",
    "phpcs": "phpcs ./ --ignore=vendor --warning-severity=0 --standard=PSR12",
    "phplint": "phplint ./ --exclude=vendor"
  }
}

The only thing I might be need after server stubs generation is to run:

$ composer test

Can I run this command using this option?

[wing328]

Code formatting is just one use case. Users can potentially run code analysis, security vulnerabilities detection tool on the auto-generated PHP files.

Besides phplint, one can also use prettier (https://github.com/prettier/plugin-php) to format the PHP code. This is not to say prettier is superior nor phplint is not good enough. We just want to give an option and let the users decide.

composer test won't fit into this use case for post-processing "individual" PHP file.

[ybelenko]

Well, I'm totally ok with that PR then, I think that somebody needs that.

As for me, I will not use prettier because it useless in CI tests. It requires Node.js with NPM/Yarn and I don't think that it's a good idea to mix PHP with Node.js on server. For local testing it might be usefull, but when you cannot confirm unit tests by server it's bad from any point of view.