Change issue closing policy from Release time to Source Fix available time

[paulb777]

From @morganchen12:

I'm ok with this, this also simplifies our tagging: instead of having "future major release" and "future minor release" tags, we could just have a "released" tag. Then querying issues that are fixed but not released becomes:

is:issue is:closed -label:released

cc: @wilhuff

[morganchen12]

After I/O:

• Deprecate the future major release and future minor release tags. All closed issues represent issues that are resolved in master, but may not be released yet.
• Introduce a new tag released. Closed issues marked with this tag are available in a Firebase release.
• Fixed but not released issues can still be queried with is:issue is:closed -label:released in GitHub's issue search.

Pros:

• We have one less tag on GitHub.
• We'll no longer have to fight GitHub's auto-close feature.

Cons:

• We'll have to retroactively add labels to closed issues (this is not so bad).
• Querying unreleased fixes becomes marginally more difficult. We can mitigate this by having a link to the unreleased fixed issues query in the README.

[morganchen12]

Source-fix time also becomes more relevant once we move to distributing source-based pods for our open components.

[wilhuff]

🙏

[paulb777]

cc:@protocol86, @morganchen12 @wilhuff @chliangGoogle @schmidt-sebastian @ryanwilson @bklimt

Now that master is targeting the next major release, we're converting to the policy of closing issues when the fix goes into master for the open source pods. Closed source pods should still leave issues open and use the "next" tags until the release.

For now, please use a comment to identify the release availability when you fix.

I'll investigate using github milestones to identify releases to simplify that process.

[morganchen12]

Previously released future minor releases have been moved to the released tag.

After the next major release, we should be able to mark all the future x release tags as released and remove the future release tags entirely.

[paulb777]

I just deleted the Future tags in favor of Milestones and created 4.12.0, M24, M25, and M26 milestones.

Now we can put a milestone on issues and PRs once and manage the timing from the milestone editor. Users can check if a milestone is available via CocoaPods on whether it is open or closed. We can rename a milestone from M* to a version number when the release branch gets cut.