Grizzly: new config file fields for LDAP

If https://review.openstack.org/#/c/14964/ gets merged:

new config options in keystone.conf

119 # user_enabled_attribute = enabled
   120 # user_enabled_mask = 0
   121 # user_enabled_default = True

   878
   879
   880 There is a set of allowed actions per object type that you can modify
   881 depending on your specific deployment. For example, the users are managed by
   882 another tool and you have only read access, in such case the configuration
   883 is::
   884
   885 [ldap]
   886 user_allow_create = False
   887 user_allow_update = False
   888 user_allow_delete = False
   889
   890 tenant_allow_create = True
   891 tenant_allow_update = True
   892 tenant_allow_delete = True
   893
   894 role_allow_create = True
   895 role_allow_update = True
   896 role_allow_delete = True
   897
   898 There are some configuration options for filtering users, tenants and roles,
   899 if the backend is providing too much output, in such case the configuration
   900 will look like::
   901
   902 [ldap]
   903 user_filter = (memberof=CN=openstack-users,OU=workgroups,DC=openstack,DC=com)
   904 tenant_filter =
   905 role_filter =
   906
   907 In case that the directory server does not have an attribute enabled of type
   908 boolean for the user, there is several configuration parameters that can be used
   909 to extract the value from an integer attribute like in Active Directory::
   910
   911 [ldap]
   912 user_enabled_attribute = userAccountControl
   913 user_enabled_mask = 2
   914 user_enabled_default = 512
   915
   916 In this case the attribute is an integer and the enabled attribute is listed
   917 in bit 1, so the if the mask configured *user_enabled_mask* is different from 0,
   918 it gets the value from the field *user_enabled_attribute* and it makes an ADD
   919 operation with the value indicated on *user_enabled_mask* and if the value matches
   920 the mask then the account is disabled.
   921
   922 It also saves the value without mask to the user identity in the attribute
   923 *enabled_nomask*. This is needed in order to set it back in case that we need to
   924 change it to enable/disable a user because it contains more information than the
   925 status like password expiration. Last setting *user_enabled_mask* is needed in order
   926 to create a default value on the integer attribute (512 = NORMAL ACCOUNT on AD)
   927
   928 In case of Active Directory the classes and attributes could not match the
   929 specified classes in the LDAP module so you can configure them like::
   930
   931 [ldap]
   932 user_objectclass = person
   933 user_id_attribute = cn
   934 user_name_attribute = cn
   935 user_mail_attribute = mail
   936 user_enabled_attribute = userAccountControl
   937 user_enabled_mask = 2
   938 user_enabled_default = 512
   939 user_attribute_ignore = tenant_id,tenants
   940 tenant_objectclass = groupOfNames
   941 tenant_id_attribute = cn
   942 tenant_member_attribute = member
   943 tenant_name_attribute = ou
   944 tenant_desc_attribute = description
   945 tenant_enabled_attribute = extensionName
   946 tenant_attribute_ignore =
   947 role_objectclass = organizationalRole
   948 role_id_attribute = cn
   949 role_name_attribute = ou
   950 role_member_attribute = roleOccupant
   951 role_attribute_ignore =