Protect development mode constant from being re-defined

[simison]

When defining GUTENBERG_DEVELOPMENT_MODE in wp-config.php and running Gutenberg master directly from the repository, we'd see PHP warnings:

[28-Feb-2019 11:39:14 UTC] PHP Notice:  Constant GUTENBERG_DEVELOPMENT_MODE already defined in /var/www/html/wp-content/plugins/gutenberg/gutenberg.php on line 13
[28-Feb-2019 11:39:14 UTC] PHP Stack trace:
[28-Feb-2019 11:39:14 UTC] PHP   1. {main}() /var/www/html/wp-cron.php:0
[28-Feb-2019 11:39:14 UTC] PHP   2. require_once() /var/www/html/wp-cron.php:39
[28-Feb-2019 11:39:14 UTC] PHP   3. require_once() /var/www/html/wp-load.php:37
[28-Feb-2019 11:39:14 UTC] PHP   4. require_once() /var/www/html/wp-config.php:89
[28-Feb-2019 11:39:14 UTC] PHP   5. include_once() /var/www/html/wp-settings.php:342
[28-Feb-2019 11:39:14 UTC] PHP   6. define() /var/www/html/wp-content/plugins/gutenberg/gutenberg.php:13

We basically wanted to install Gutenberg (plugin version, not this repo) in development mode to Jetpack-Docker development environment by default. That's not a problem until someone runs Gutenberg from master and then gets these PHP warnings.

Came up in Automattic/jetpack#11439 (review)

Now, I get this is in between AUTO-GENERATED DEFINES comments so there's probably a place somewhere else where I should PR. Happy to do so. :-)

How has this been tested?

Define constant in your wp-config.php or wp-content/mu-plugins folder and observe Gutenberg not trying to double-define it.

Types of changes

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.
• I've included developer documentation if appropriate.

[aduth]

This seems like a reasonable enhancement. I had to refresh my history on how these auto-generated lines are treated, since at a glance it seemed the wrong place to make the change. On further investigation, however, it appears correct. It's located here so that it becomes removed as part of the plugin build and replaced instead with production defines (source). I'm not positive about the conventionality of defined( 'x') or define( 'x', true );, but it's valid in assigning-when-not-assigned, and seems preferable to keep aligned to a one-per-line define of this segment of code.

I rebased the branch since it was quite stale and Travis would not complete or restart.