Revision 1812193

Follow up to r1740928: including NOT_IN_PROXY in NOT_IN_DIR_LOC_FILE is both
incomplete and not backportable, fix it by introducing NOT_IN_DIR_CONTEXT and
restoring NOT_IN_DIR_LOC_FILE to its previous value.

Per ap_check_cmd_context(), NOT_IN_DIR_LOC_FILE actually/really means "not in
any directory context", while the definition itself does not include all the
existing directory contexts (e.g. <Limit>, or <Proxy> before r1740928).

This is a bit of a misnomer, at least, so instead of (ab)using it by adding the
missing contexts (in an incompatible way), let's define NOT_IN_DIR_CONTEXT to
really exclude all directory context (i.e. NOT_IN_DIR_LOC_FILE + NOT_IN_LIMIT +
NOT_IN_PROXY) and use it wherever NOT_IN_DIR_LOC_FILE was used.

This is by itself a major MMN bump (modules not compiled with this commit and
having directives checked against NOT_IN_DIR_LOC_FILE won't be caught the same
way by NOT_IN_DIR_CONTEXT in the new ap_check_cmd_context() code), but with the
below change, 2.4.x should work as before:

-   if ((forbidden & NOT_IN_DIR_CONTEXT) == NOT_IN_DIR_CONTEXT) {
+   if ((forbidden & NOT_IN_DIR_LOC_FILE) == NOT_IN_DIR_LOC_FILE) {
        if (cmd->path != NULL) {
            return apr_pstrcat(cmd->pool, cmd->cmd->name, gt,
-                           " cannot occur within directory context", NULL);
+                           " cannot occur within <Directory/Location/Files/Proxy> "
+                           "section", NULL);
        }
        ...
    }