fix(chart): Improve default value for videoRecorder

[VietND96]

Thanks for contributing to the Docker-Selenium project!
A PR well described will help maintainers to quickly review and merge it

Before submitting your PR, please check our contributing guidelines, applied for this repository.
Avoid large PRs, help reviewers by making them as simple and short as possible.

Description

Improve default value for videoRecorder in chart after #1881

Motivation and Context

Currently, by default, videoRecorder.enabled=false. When enabling videoRecorder, with default uploader: s3 in chart values.yaml. User must input the appropriate value for uploadDestinationPrefix. Otherwise, the video container will be exited immediately (as video.sh in ConfigMap implemented).
In my point of view, in common use cases, not always the user has S3 destination ready. Basically, by default, all containers in the pod should be up fully before going to advanced configs. Use cases with the order of priority would be

1. Default videoRecorder.enabled=false. Node pod has 1/1 container running.
2. User configure --set videoRecorder.enabled=true only. Node pod has 2/2 containers running. Video records are persisted in PersistentVolume in Kubernetes.
3. User continue configure the uploader and upload destination --set videoRecorder.uploader=s3 --set videoRecorder.uploadDestinationPrefix=s3://myvideobucket/. Node pod has 3/3 containers running, and records are uploaded properly to destination S3.

Update to use the boolean value false to disable the uploader and skip upload by default.

Update ENV VIDEO_LOCATION -> SE_VIDEO_FOLDER to align with existing ENV present in video image selenium/video:ffmpeg-6.0

Update in chart templates:

• Wrap (.Values.videoRecorder.uploader | toString) to work with case value uploader: false. Avoid Helm raise the error: at <.Values.videoRecorder.uploader>: wrong type for value; expected string; got bool
• Add | quote for .Values.videoRecorder.uploadDestinationPrefix is able to to work with bool value input

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist

• I have read the contributing document.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have added tests to cover my changes.
• All new and existing tests passed.

[diemol]

Thank you, @VietND96!