Add documentation for WordPress.PHP.DevelopmentFunctions

[gogdzl]

Related to #1722

[rodrigoprimo]

Thanks for working on this PR, @gogdzl! I'm not a maintainer of the project so take my review with a grain of salt. That being said, I left some comments based on my own experience creating PHPCS and WPCS sniffs.

[rodrigoprimo]

Suggested change

	Typically, this rule verifies if function calls to the PHP native `error_log()`, `var_dump()`, `var_export()`, `print_r()`, `trigger_error()`, `set_error_handler()`, `debug_backtrace`, `debug_print_backtrace` and `wp_debug_backtrace_summary()` functions are present in the code.
	This rule verifies if calls to the `error_log()`, `var_dump()`, `var_export()`, `print_r()`, `trigger_error()`, `set_error_handler()`, `debug_backtrace()`, `debug_print_backtrace()` and `wp_debug_backtrace_summary()` functions are present in the code.

I'm suggesting the removal of the PHP native part as wp_debug_backtrace_summary() is not a PHP native function.

[rodrigoprimo]

Maybe instead of verifies, we could use warns to more accurately describe what the rule does? Just thinking out loud here.

[rodrigoprimo]

I know that this is the warning message displayed by the sniff, but I believe that the documentation (and maybe also the sniff messages) usually only uses should/should not when describing an error. Since this is a warning, maybe we could say that it is recommended or something like that?

[rodrigoprimo]

Why not is in between parenthesis?

Also, I wonder if the message should be more generic and mention debug code/functions instead of singling out var_dump()? I'm ok with a single example with just var_dump().