Core Gadget - Security Policy

This is a DRAFT.... currently, the Security Policy Feature section is buried inside the element definitions for ModulePrefs... this is silly. This rewrite pulls it out into it's own section and removes the definition of the el_escaping permission which should be defined elsewhere when dealing with the Expression Language stuff..

  <section title="Security Policy Feature" anchor='SecurityPolicy'>
    <t>Gadget's often require the ability to perform potentially 
    dangerous or sensitive operations or work with sensitive information.
    Such gadget's SHOULD only be allowed to perform those operations 
    if explicitly granted permission to do so by the container or the
    user.</t>

    <t>The Security Policy feature is used by a gadget to request 
    permissions under which to run.  Specific permissions are requested 
    with &lt;Param&gt; elements, with the "name" attribute on the 
    Param element identifying the feature and the text content of
    the element providing any additional required feature-specific information. 
    The Security Policy feature is specified within the &lt;ModulePrefs&gt;
    with the feature name "security-policy" using either the &lt;Optional&gt;
    or &lt;Require&gt; element. A container MAY support the 
    Security Policy feature.</t>

    <t>Containers MAY override any gadget-request permission with its 
    own security policy.</t>

    <figure><preamble>A gadget requesting optional permissions from the 
    container:</preamble><artwork xml:space="preserve">
  &lt;ModulePrefs &gt;
    &lt;Optional feature="security-policy" &gt;
      &lt;Param name="foo"&gt;bar&lt;/Param&gt;
    &lt;/Optional &gt;
  &lt;/ModulePrefs &gt;
    </artwork></figure>  

    <t>If an application requests a security policy that is not supported, 
    the container MUST log an error to the gadgets.log.  A container MAY 
    render that gadget using a supported security policy, or display an 
    appropriate error message. TODO: Clarify this</t>

    <t>Containers are free to define their own permissions for any purpose.
    TODO: should we have a registry of common permissions???</t>

    <t>TODO: Move the definition of the el_escaping permission to the 
    appropriate different location in the spec</t>
  </section>