WL#4989: Allow plugins to access the component registry

The old plugin infrastructure has a lot of plugins. Converting them to the
component infrastructure is no easy task. This worklog will provide an old
plugin service API for the old plugins to access the registry and its services. 
This is needed to allow gradual migration of functionality from the old plugin
infrastructure to the new one.

User Documentation
==================

* http://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-1.html
* http://dev.mysql.com/doc/refman/8.0/en/plugin-services.html

FR1: A new plugin service will be added with 2 methods that will call
Registry::aquire() and Registry::release() of the default
registry implementation, currently the only implementation inside the server
component
NF2: No need for Registry::acquire_releated() since at all times there will be
only one default registry that all components need to interact with 
NF3: Calls to the new plugin service are to be considered "expensive" due to the
need to do write access to the registry globals.
NF4: No SQL level changes will result from this worklog
FR5: Each call to the acquire methods() needs to be coupled with a release()
call so that no resources are leaked

= The plugin service =

To allow "traditional" plugins to interact with the registry we define the
following plugin service (named "plugin_registry_service" with version 1.0): 

/**
  @ingroup group_ext_plugin_services
  A bridge service allowing plugins to work with the registry.

  This allows traditional MySQL plugins to interact with the service
  registry.
  All this plugins service does is to return a reference to the
  registry service.
  Using that the plugins can access the rest of the registry and
  dynamic loaders services, as well as other services present in the
  registry.
  Note that the plugins must release the service references they
  acquire otherwise resources will be leaked and normal unload order
  may be affected.
*/
extern struct plugin_registry_service_st
{
  /**
    Acquire a pointer to the registry service

    The reference must be released by calling
    plugin_registry_service_st::mysql_plugin_registry_release_func()
    See @ref mysql_plugin_registry_acquire() for more details.

    Once you receive the registry pointer you can use it to aquire
    references to other services your plugin might be interested in.

    @note
    This is to be considered an "expensive" operation because it
    requires access to the global structures of the
    @ref PAGE_COMPONENTS_REGISTRY. Avoid using it in situations
    where fast and scalable execution is requred.
    Since the registry service is very unlikely to change often
    holding on to the reference to it for extended time periods
    is a safe bet.

    @note
    Achieveing scalability through preserving references does not
    come for free.
    These are some of the effects on code that caches active
    references:
    - components implementing services to which active references
    are held cannot be unloaded.
    - code keeping an active refernece to e.g. a default service
    implementation will not switch to a possible new default
    service implementation installed by a component loaded in
    the meanwhile, as taking the updated default service implementation
    would only happen at the time of aquiring a new reference.

    @return the registry pointer

    See also: @ref PAGE_COMPONENTS, @ref PAGE_COMPONENTS_REGISTRY,
    @ref mysql_plugin_registry_acquire(), @ref mysql_plugin_registry_release()
  */
  SERVICE_TYPE(registry) *(*mysql_plugin_registry_acquire_func)();
  /**
    Release a pointer to the registry service

    Releases the reference to the registry service, as returned by
    @ref mysql_plugin_registry_acquire().
    After this call the reigstry_ptr is undefined and
    should not be used anymore.
    See @ref mysql_plugin_registry_release() for more details.

    @warning
    Before releasing the reference to the registry service please
    make sure you have released all the other service references
    that you explicitly or implicitly acquired. These can't be
    released without a valid reference to the registry service.

    @note
    This is also to be considered an "expensive" operation.
    See @ref plugin_registry_service_st::mysql_plugin_registry_acquire_func
    for more details on pros and cons of re-acquiring references vs caching
    and reusing them.

    @param registry_ptr   the registry pointer
    @return execution status
    @retval 0 success
    @retval non-zero failure

    See also @ref PAGE_COMPONENTS, @ref PAGE_COMPONENTS_REGISTRY,
    @ref mysql_plugin_registry_release(), @ref mysql_plugin_registry_acquire()
  */
  int (*mysql_plugin_registry_release_func)(SERVICE_TYPE(registry) *registry_ptr);
} *plugin_registry_service;

Note that it will operate on a global, static pointer to the service registry so
no locking in the service implementation itself is necessary or will be done.
The registry and its services do their own locking as needed.

The relevant service methods will call registry::acquire() and
registry::release() methods. This are to be considered "expensive" and should
not be done in any critical path.

= The test =

A daemon plugin will be developed that will test the above two services at its
init() method by doing the following:
    - acquire the registry_registration service default implementation
    - register a new service implementation for the mysql_server component
    - acquire the newly registered service's default implementation
    - compare the service handles for equality
    - release the service handle for our service
    - unregister our service
    - release the handle to the registry registration service

A test script will be developed that will call INSTALL PLUGIN for the new
testing daemon plugin.

Check the doxygen documentation for the service and the implementation functions.