Add possibility to chooses to use https or http for links

[EHoglid]

For new features:

• [x] Describe the use-case in details In Sorry Cypress you always assume that the connection to GitLab, GitHub or other web based git platforms are https:// but that is not always the case. If you for example have a self maintained environment then it is possible that this is not configured and you only use http://. I have configured a variable USE_SSL_FOR_LINKS that can be set the director part when creating the director in docker. 'true' = use https:// 'fasle' = use http://

Also I discovered that in the dashboard it do the same thing as in the director, converting git@ to https:// so I removed that function handleSshUrl. The getRemoteOrigin() function now takes a argument if it should return http or https.

• [x] Ensure the solution is backwards-compatible By setting the default value to 'true' this should be backwards-compatible

• [x] Test it. Submit screenshots / outputs / tests together with the PR. Created a own docker and pulled the image and tested it on my computer. (ehoglid/sorry-cypress-....) All test passed and extended the test for getRemoteOrigin() to test the extra argument and check if the return is OK.

USE_SSL_FOR_LINKS: 'false'

USE_SSL_FOR_LINKS: 'true'

No argument in docker, default should be https (backwards-compatible)

[mathpaquette]

@EHoglid I dont understand we why need an option for it ? Technically it should be automatically handled no ?

[EHoglid]

@mathpaquette It depends, normally you can have a settings that redirect http to https if you support https. But in my case our GitLab isn't setup with https, then you can't handle https requests at all. Second, I have never heard that you redirect a https request to http, that would be a security issue. Therefor it would be good to choose if it should be http or https. Of course https is the preferred solution because it is a encrypted connection but in our case it is a local server in a closed environment, therefore it has never been setup.

But I do not see any issue of supporting both? https is the default value anyway, so it won't affect any users if this is implemented.