WL#4596: Plugins: a plugin may be mandatory or optional

This worklog task was created as a result of discussion in BUG#19027 "MySQL 5.0
starts even with Fatal InnoDB errors".

A plugin may be required in one installation, and optional in another. 
It should be possible to configure that.

Possible solutions:

1) Configuration in plugin description.

Extend the plugin interface, in particular, the plugin description, with
a new member is_mandatory={TRUE/FALSE}.
 The service interface would be responsible for loading and unloading
plugins. The 'is_mandatory' property should not be part of a plugin interface,
but of a plugin-management interface since each isolated plugin should not have
to carry the burden of knowing the entire surrounding architecture. The
_internal_ plugin structure could of course benefit from a variable indicating
what the management system should do with it.

2) Extend semantics of --enable-, --disable, and --loose in the option
files.

--enable means mandatory
--loose-enable means optional.
The default is --loose-enable.

Since some plugins (e.g. InnoDB) have historically been mandatory,
we should be careful to not break the backward compatibility when 
introducing the change. If we do decide to break the backward compatibility,
it should be done in a major version only, with proper documentation
warning and an entry in the upgrade procedure.

 To accommodate backward compatibility I think BUG#19027 should be
solved by hard coded directives on how to handle InnoDB SE and this should be
considered a temporary solution until the service API is installed. Using the
service API suitable plugin loading dependencies could be configured.

One issue in bug 19027 is that applications using the database assumes that the
meta data is durable and is present when the server is online. The lack of
durability is addressed in WL#2760. Example: If a SE plugin fails to load the
client applications should not be able to operate on the corresponding objects
because the 'super database' would not allow it, ie the objects are "offline".

Creating a language of command line options and settings will not scale and
doesn't help our goal of creating a modular environment. There will of course
always be exceptions to any strategy, but in this case we should simply follow
the strategy before introducing exceptions.