fix(pdk) ensure 'kong.ctx.plugin' and 'kong.log' are light-threads safe

[thibaultcha]

This PR replaces #5851 because it provides a more robust implementation and fixes several other issues.

kong.ctx

• Store namespace keys in ngx.ctx to ensure all dynamically generated namespaces are isolated on a per-request basis.
• Introduce a new global API (which is a private API for use by core only) to explicitly delete a namespace.

A note on the benefits of this new implementation compared to #5851:

• By using a table to keep track of namespaces in ngx.ctx, we ensure that users of ngx.ctx cannot access the table namespaces, thus properly isolating it and avoiding polluting ngx.ctx for core and/or plugins. We can think of it as a double-pointer reference to the namespace. Each request gets a pre-allocated table for 4 namespaces (of course not limited to 4), with the assumption that most instances do not execute more than 4 plugins using kong.ctx.plugin at a time.
• We ensure that namespace key references cannot be nil to ensure a safe usage from the core.
• All namespace key references are still weak when assigned to a namespace, thus tying the lifetime of the namespace to that of its key reference. Similarly to the previous implementation, this is done to
  ensure we avoid potential memory leaks. That said, the kong.ctx.plugin namespace does use the plugin's conf for that purpose anymore (See 40dc146), which alleviates such concerns in the current usage of this API.
• All tables allocated for namespace key references and namespaces keys themselves will be released when ngx.ctx will be GC'ed.
• We also ensure than kong.ctx.* returns nil when ngx.ctx is not supported ("init" phase).

kong.log

• Store current logging facility in kong.ctx.core to ensure that multiple concurrent request do not share the same kong.log Lua global facility.
• Log facilities are still cached in a local upvalue to avoid re-recreating them for every incoming request.

A note on the current implementation: unlike the kong.ctx PDK module, the kong.log module does not encapsulate its namespacing capabilities. Doing so would be more efficient, as we would avoid having to create multiple kong.log instances. Instead, a singleton instance could keep track of the different namespaces (and their assigned logging formats) itself.

Fix #4379
Fix #5853
Fix #5057
See #5851
See #5459

[kikito]

Most of my comments were cosmetic / low importance. But I think the changes in the tests might be needed.

[thibaultcha]

@kikito Thanks! I pushed a revised version, will wait until CI yields green again and merge.