fix: Refactoring the download process for StaticSiteClient

[shibayan]

Fixed an issue where ETXTBSY and EBUSY errors would occur when executing processes using spawn after the download process ran when StaticSiteClient did not exist.

In this PR, we simplified the close processing and error handling after downloading the file by using the Streams Promises API, and stabilized the download process.

I wrote the following workflow and checked the failure rate of the swa deploy command in the branches before and after the improvement.

jobs:
  deploy:
    runs-on: windows-latest
    steps:
    - uses: actions/checkout@v4
    
    - uses: actions/checkout@v4
      with:
        repository: shibayan/static-web-apps-cli
        ref: deploy-client-download
        path: static-web-apps-cli

    - name: Build SWA CLI
      run: |
        npm install
        npm run build
      working-directory: ./static-web-apps-cli

    - name: Deploy to Static Web App
      run: node ./static-web-apps-cli/dist/cli/bin.js deploy ./dist/ --env production

deploy-new.yml is the workflow that uses the fixes in this PR. I can see that the deployment stability has improved significantly, as the failure rate of the workflow after the fixes is 0%, whereas the failure rate of the workflow before the fixes was over 60%.

Fixes #721
Fixes #799
Fixes #916

[shibayan]

@Timothyw0 @cjk7989 I consider this to be a fairly critical issue, so it would be very helpful if you could review it 🙏 Thanks!

[mohamedfarees]

Based on test result, LGTM, It will be great if this fix goes to live

[dvasdekis]

@Timothyw0 and @cjk7989 are you able to review this pull request? We are an Azure Enterprise customer and this is creating issues for us. Happy to include our account manager if that would expedite it