Removes default-allow? policy flag in favor of default policies.

When looking at configuring fluree/server for zero-trust, it introduced the challenge of specifying a config for default-allow? on a per ledger basis. This made it clear that this behavior really belonged as part of the policy itself, and such a config shouldn't be needed.

Having the 'default' behavior part of the policy also offered these enhanced capabilities:

1. instead of true/false, any policy query could be defined as the 'default', allowing more granular control.
2. Different users/identities might have different default behavior
3. Default policy behavior is co-resident with other policy behavior
4. Default policies are defined the identical way as property or class policies, so one thing to explain

As we look to have zero-trust mode, this also makes it possible to create a 'root' policy (just a default policy that always returns truthy) and attach it to an identity, presumably the same identity that created the ledger. This is how v2 worked.

Creating a 'root' policy is just like any other policy, except there is no f:onProperty or f:onClass specified (thus, default). The following is the most permissive/simple example of a root policy:

{"@id"      "ex:defaultAllowViewModify"
 "@type"    ["f:AccessPolicy" "ex:RootPolicy"]
 "f:action" [{"@id" "f:view"}, {"@id" "f:modify"}]
 "f:query"  {"@type"  "@json"
                    "@value" {}}}

To attached an identity to the above policy, just use f:policyClass set to the @type in the policy define above (ex:RootPolicy):

{"@id"          <some-root-did-here>
 "f:policyClass" [{"@id" "ex:RootPolicy"}]}

While any query where condition can be specified for f:query - an empty map has no where condition, so it allows ?$this to just flow through (truthy).