"security-token" as feature

This patch defines a new feature, "security-token", whose purpose is to serve as the definitive signal indicating when a gadget requires a security token.

At present, this determination is made via a number of heuristics. The implementation in this patch codifies these rules in a central location:
* Gadget includes feature opensocial-*
* Gadget includes feature osapi
* Gadget has <OAuth> tag

Still unaccounted-for: signed fetch via gadgets.io.makeRequest.

The security-token feature in turn has two dependencies, for separate reasons:
1. "auth-refresh" At present, in order to support security token refreshing, a container must know (via similar heuristics to above) to append &libs=auth-refresh to a gadget render, which forces inclusion of the auth-refresh gadgets.rpc handler. With this change, the JS is included automatically when a security token is needed.
2. "locked-domain" Without this change, locked domain is enforced only when actively opted-in by the gadget (the code performs a transitive closure of dependencies to discern locked-domain qualification, but no features actually have this dependency in Shindig). This leads to a scenario in which a gadget may be rendered on an insecure domain.

In order to prevent a large number of gadgets from suddenly rendering on locked-domain without the rendering party's explicit knowledge, the patch includes a provision forcing opt-in to transitive locked-domain support. Note, this causes non-Shindig features with locked-domain dependencies to no longer render on locked-domain!

For this reason, and in general due to locked-domain implications, I'm especially keen to hear others' opinion on the strategy as implemented.