Improve AlgoKit CLI compatibility with execution via pyinstaller binaries

[aorumbayev]

Description

AlgoKit cli when packaged as a pyinstaller binary, has a set of issues when executed in that mode.

1. algokit task vanity-address requires patching to encorporate multiprocessing.freeze_support() to be enabled in __main__.py to prevent execution failures when running in binary.
2. algokit init fails on any copier task execution. Requires aliasing of algokit deploy command into algokit run command that can be invoked from a template instead of relying on _copier_python variable. Cli should figure out the right user's default python interpreter to pass the invocation to via subprocess.

Technical Details

• It is advisable to implement a helper method inside cli that serves to identify whether algokit is invoked via binary or via invocation of the wheel.

Acceptance Criteria

• algokit task vanity-address command works in binary execution mode
• algokit init works on any copier template relying on _tasks where invocation of python script is invoked via algokit run
• Documentation for algokit run is available on the cli repository
• Updated CI/CD pipelines by introducing portability tests that verify main algokit cli flows by testing freshly build binary artifacts

Tasks

• - patched vanity-address command in binary mode
• - patch copier tasks compatibility in binary mode
• - documented algokit run

---

TODO Refine conventions

The hierarchy so far:

1. Milestone/Outcome - defined on an individual repo (case sensitive)
2. Features - defined as github issues - the specific type identified by tag named feature
3. Task - defined as a github issue - serves as a smallest measurable unit of work - identified by tag named task