feat: add posthog telemetry

[avallete]

Closes: CLI-1243

[coveralls]

Pull Request Test Coverage Report for Build 23950082888

Details

• 462 of 643 (71.85%) changed or added relevant lines in 18 files are covered.
• 8 unchanged lines in 3 files lost coverage.
• Overall coverage increased (+0.4%) to 63.599%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
internal/start/start.go	4	8	50.0%
internal/telemetry/project.go	36	43	83.72%
internal/link/link.go	26	36	72.22%
internal/telemetry/client.go	73	84	86.9%
internal/telemetry/state.go	58	74	78.38%
internal/login/login.go	16	35	45.71%
cmd/telemetry.go	6	29	20.69%
cmd/root_analytics.go	101	126	80.16%
internal/telemetry/service.go	129	156	82.69%
cmd/root.go	0	39	0.0%

Files with Coverage Reduction	New Missed Lines	%
cmd/root.go	1	8.84%
internal/storage/rm/rm.go	2	80.61%
internal/utils/git.go	5	57.14%

Totals
Change from base Build 23940539189:	0.4%
Covered Lines:	9681
Relevant Lines:	15222

---

💛 - Coveralls

[seanoliver]

Tested locally with PH staging project and everything looks great!

The env_signals property is 🔥 — this is going to be super useful for segmentation.

[pamelachia]

one thing from the telemetry side: the 4 events are defined as inline strings at each call site. on the frontend we have telemetry-constants.ts that acts as a registry for every event with documented properties for each event, which makes it easy to see what's being tracked, keep naming consistent, and lets data people know what to expect without reading through the Go code.

would it be possible to add something similar for the CLI? even just a constants file in internal/telemetry/ with all event names and expected properties in one place. makes it way easier for us to track what exists and catch naming issues before they ship