Clarify policy on working in the open, rewrite/merge team guidance

This PR updates #13 to be in line with [my proposal in #16](https://github.com/18F/open-source-policy/pull/16#issuecomment-55481501). If this is merged, #13 will be updated in-place, and I'll take that as a sign that #13 is done and I'll merge that too.

When our open source policy was written, it left some ambiguity about whether we were committing ourselves to releasing all source code eventually, or on day 1 of a project. This has led to us using the "rare, and documented publicly" exception for source code release to specify constraints around situations where we may temporarily delay source code release.

I think it's important that our exceptions to eventual source code release be very clear, and very narrow. They form the normative floor of our work, and I think we came out with some strong language. We risk diluting them if we try to fit every possible reason for temporary open source delay inside that framework.

I also think it's important that we have strong 18F norms around working in the open, and don't allow common traps like "After it's documented" or "It's too embarrassing" or "the client doesn't get it" to keep us from working in public the way that our values and our audience expect us to.

I've merged `exceptions.md` and `team-faq.md` into `practices.md`, titled it "Practicing our open source policy", and designed it as a document for team guidance.

https://github.com/18F/open-source-policy/blob/harmonize/practice.md#practicing-our-open-source-policy

It covers how and why to dedicate our work under CC0, why we work in public and some situations where we might temporarily delay release, and our narrow exceptions to eventual source code release.

When discussing the situations where we may delay release, I've toned down their wording to be less policy-like, but to remain very clear about expectations. I've given it some surrounding context, and team members are told to consult with the team before proceeding on a software project in private if their situation doesn't appear among those listed.

I've also **[tweaked the policy language](https://github.com/18F/open-source-policy/commit/027f4984b2488ecbfbe66390240a2195c3fbb570#diff-1)** to match what I proposed in https://github.com/18F/open-source-policy/pull/16#issuecomment-55481501.

I don't think any of my changes actually substantively change the policy &mdash; this is always what we intended, I'm making it more clear. I'm looking for signoff on this from at least @rjmajma, @seanherron and @aaronsnow before merging.
Ok, so let me again ask: What happens to projects that were developed in private, but then cancelled?

And what happens to non-code artifacts in general (Issue trackers, design docs, personas)? Developing in the open will generally result in those artifacts being public as well, but with after the fact releases, not so much.