gracefully handle analytics error

[yen-tt]

Throw error from not having ytag script tag for conversion tracking opt in would prevent a search fired on load. This is an aggressive behavior as analytics shouldn't affect search behavior. This pr updated the two throw error into console error instead.

Same as https://github.com/yext/answers-search-ui/pull/1771 but without acceptance tests changes

TEST=manual

Added ANSWERS.setConversionsOptIn(true); to a local index page with Answers setup. see that the previously uncaught throw error is now a console error and a search on load is no longer blocked.

[nmanu1]

also, I was just curious, so I looked it up and generate-license-file released a new major version a couple days ago, which is why the third party notices changed. we don't pin to any major when installing the package in the GH action

[yen-tt]

any idea why code coverage is failing? besides that, lgtm!

the default for comparision_branch for coverage workflow is "main" which we have "master" instead for SDK. updated in this pr to point to master

[yen-tt]

also, I was just curious, so I looked it up and generate-license-file released a new major version a couple days ago, which is why the third party notices changed. we don't pin to any major when installing the package in the GH action

A quick look at the release notes for v2 and the changes seem ok? We can make an item or a separate pr to pin to v1 in the reusuable workflow repo or pin to v2 and probably have to update the version package.json to v2 in our repos as well so it's consistent

[nmanu1]

A quick look at the release notes for v2 and the changes seem ok? We can make an item or a separate pr to pin to v2 in the reusuable workflow repo.

Yeah, that's what I was thinking. There weren't any breaking changes on the running side, only on the output produced and those changes seem fine. But, that might not be the case if they release a v3, so it would be good to pin to v2 in another item