Polish Xcode integration

[kelson42]

• I find odd that the libkiwix version is defined in the Brewfile. libkiwix is our top dependency and exposing it solely in a URL in the Brewfile feels hackish.
• This PR doesn't update the CI and CD workflows which now relies on this mechanism. We thus end up with a LIBKIWIX-VERSION environ on those files that makes it look like it controls the version used while it doesn't anymore.
• README says that the Brewfile will install latest CoreKiwix. That's not true. It will install the version specified in the brewfile. We have a URL for the latest version but we're not using it (on purpose) so this sentence is misleading.
• DEVELOPMENT_TEAM is not a secret value but it's part of the several values associated with signing. In all repos we need them, we store it as a secret for convenience: when updating signing params, everything's in the same place. Given it doesn't change when certificates are renewed, we should remove it from the secrets… but you need to remove it from the places that are looking for it (CI, CD).

Reported at #606 (comment)

[kelson42]

• I find odd that the libkiwix version is defined in the Brewfile. libkiwix is our top dependency and exposing it solely in a URL in the Brewfile feels hackish.

@rgaudin What would be an better altenative approach?

* This PR doesn't update the CI and CD workflows which now relies on this mechanism. We thus end up with a `LIBKIWIX-VERSION` environ on those files that makes it look like it controls the version used while it doesn't anymore.

@BPerlakiH Why?

* README says that the Brewfile will install **latest** CoreKiwix. That's not true. It will install the version specified in the brewfile. We have a URL for the latest version but we're not using it (on purpose) so this sentence is misleading.

Dependencies version should be explicit anyway. Readme should be fixed.

* `DEVELOPMENT_TEAM` is not a secret value but it's part of the several values associated with signing. In all repos we need them, we store it as a secret for convenience: when updating signing params, everything's in the same place. Given it doesn't change when certificates are renewed, we should remove it from the secrets… but you need to remove it from the places that are looking for it (CI, CD).

I prefer the secret for convenience, but if this approach is proven to be combersome, then lets hardcode it everywhere. In any case, this has to be fixed.

@BPerlakiH Please treat ticket in priority.

[BPerlakiH]

I've addressed these issues here: #610

The Development Team value. Yes, I think that can be removed from secrets, I do not think it is a priority atm.

The team id value contained in the project file is only a default one, and can be overwritten both in the building, and later in the code signing process. For these reasons, I think it can be treated separately.

The code signing part is really a separate step. It is so much separated, that in theory even a different team id can be used to sign the final app. I think, at the very end of the review process Apple even re-signs all the apps once more, before they make it to the App Store in their final form.

Since we are about to update the code signing / releasing part of our process (to fastlane + match), I would like to leave this part for later.

I will keep in mind that we should ideally have a single source of truth for the value of the team id, if that's possible.