Take php-executable from php-core instead of guessing at it

[zonuexe]

Follow-up from #815, now that php-core.el exists.

The problem

php-project.el and php-flymake.el both wanted php-executable and neither could say so. php.el requires php-project, so php-project requiring php.el back would have been circular; php-flymake.el is pulled in by php-mode.el for the same reason. Both worked around it by testing whether the variable happened to be bound:

;; php-project.el
((boundp 'php-executable) php-executable)
(t (executable-find "php"))

;; php-flymake.el
(list (or (bound-and-true-p php-executable) "php"))

The fix

php-core.el holds php-executable and depends on nothing, so both files can require it and ask for the variable directly. No cycle — php-core requires nothing, and php.el already requires both php-core and php-project. Verified that (require 'php-project) and (require 'php-flymake) each load standalone.

The fallback branches go away. They were only ever reached when php.el had not been loaded, which can no longer happen for this variable.

The one behaviour change

With no PHP installed, php-project-get-php-executable returned nil in that php.el-not-loaded case and now returns "php". That is exactly what php-executable itself defaults to — (or (executable-find "php") "php") — so the two now agree instead of disagreeing. It has no in-tree callers; it is public API documented in php-project.el's commentary.

Verification

no project setting	/opt/homebrew/bin/php (unchanged)
project setting, executable	that path (unchanged)
project setting, missing file	falls through to php-executable (unchanged)
no PHP installed	"php" (was nil only when php.el was unloaded)

Byte-compiles with no new warnings (the two rx any warnings in php-flymake.el are pre-existing and only shift by a line); full suite green.