feat(updater): separate intel and apple silicon targets, closes #3359

[lucasfernog]

What kind of change does this PR introduce?

• Bugfix
• Feature
• Docs
• New Binding issue #___
• Code style update
• Refactor
• Build-related changes
• Other, please describe:

Does this PR introduce a breaking change?

• Yes, and the changes were approved in issue #___
• No

Checklist

• When resolving issues, they are referenced in the PR's title (e.g fix: remove a typo, closes #___, #___)
• A change file is added if any packages will require a version bump due to this PR per the instructions in the readme.
• I have added a convincing reason for adding this feature, if necessary

Other information

[JonasKruckenberg]

I think this solution doesn't scale well, think about windows on ARM for example.

If it has to be s breaking change (which I also think it has to) then let's make it a proper 3rd parameter to the URL.

[FabianLars]

As said on discord i agree with jonas.
Furthermore, what about darwin universal? Ofc this can be handled server side by just providing the universal bundle no matter the arch, just wanted to make sure we think about that and (officially) set on an approach here

[JonasKruckenberg]

I propose we create two new variables that can optionally be present in the URL: target_arch target_os.

Those variables are replaced by their equivalent cfg!(<variable>) values for predictability.

While we're at it we can also consider exposing target_feature, target_endian, target_pointer_width and debug_assertions for good measure. The former can be helpful when sidecar binaries are at play and the last for opting users into a "debug build" channel

[JonasKruckenberg]

Looking good 👍🏻

[JonasKruckenberg]

I think this is not up to date anymore correct?

[lucasfernog]

oops didn't see this one, thanks