Add analytics to monitor which features are used the most

[maciekstosio]

It would be good to gather some analytics. At this point, I'm thinking about sending selected options and if it's the first time used or consecutive - that shouldn't require us any consent from the user - to confirm. It would be good to decide if we want to use SAS or self-hosted simple server. If we're going for self self-hosted solution I would just create supabase project. That would allow us to set it up really fast.

[km1chno]

My proposition:

How

• supabase sounds cool
• opt-out with CLI flag
• (transparency!) display information about gathering data at the start of the script + in readme + in documentation
• each run of npx setup-ci should result in one telemetry object sent
• if telemetry is not sent due to an error (e.g. connection error), the script should not throw and not even print anything (the user doesn't care it failed)
• easily extendable telemetry object for future modifications (but note that supabase uses relational database, so changes might require data migration to new tables)

Telemetry object (what is collected)

{
    timestamp: string, // perhaps in UTC
    version: string, // setup-ci version
    env: {
        os: string, // only (mac|linux|window) or with (kernel) version
        expo: boolean // true iff project is expo
    },
    firstUse: boolean, // true iff setup-ci has not been run in the project yet
    args: string[], // cli arguments
    recipe: {
        // object representing what was selected by the user
        // or evaluated from provided cli arguments
        main: string[], // processes for main branch
        feature: string[], // ... for feature branch
        release: string[]  // ... for release branch
    },
    error?: string // only if occurred
}