There are some scenarios in which it is possible for multiple calls to the executor to occur at the same nesting level for the same query. This includes, at the very least, when SQL functions are called. As protection against the SQL function case in particular, but also as insurance against other cases that may emerge, record the SQL text (EXPLAIN... prefix and all) to be explained within pg_stat_plans_explain, and then verify that it is consistent with the query descriptor sourceText indicated within pgsp_ExecutorEnd().
This could happen in case a database session has set a search_path to a schema not accessible by the current role for example. This results in an empty activeSearchPath list, which is returned by fetch_search_path() as an empty list. Access in get_search_path_xor() then causes a crash. The best solution to this seems to also include any implicit search_path members, too. This also seems to be a more correct definition in the sense of a "stable" view when evaluating the plans later.
This infrastructure can be used to debug problems with pg_stat_plans fingerprinting logic. When the macro STATS_PLAN_DEBUG is defined, Postgres will print a low-level representation of each plan tree that is fingerprinted, as it is fingerprinted. Add documentation on how to debug problems with pg_stat_plans' fingerprinting logic, including using this new infrastructure.
This is just a cosmetic adjustment, since naturally pg_find_plans was not relying on a particular column ordering. In passing, change the spelling of a few words appearing in README files so that American English spelling is used, per project policy.