feat(core)[OASIS-6054]: Change Error to LOG_LEVEL.WARNING for unfound event (#418)

## Summary
- Log a warning when an event key is not found in the datafile instead of throwing an Error
- Log a warning mentioning that user tracking is not happening
- Update actual error logger in catch to be an ERROR instead of INFO
- Updated CONTRIBUTING.md instructions with CHANGELOG.md update instructions

In a similar vein as optimizely/java-sdk#361, the JavaScript SDK noise could be more configurable for use with integrations like Segment.

_Note:_ Please pardon the prettier noise. I tried to do a prep PR in #419 but there are still changes when I save. The actual functionality changes are in 646665d.

## Test plan
- Updated unit test to cover new functionality
- Ensure other tests pass

## Issues
- [OASIS-6054](https://optimizely.atlassian.net/browse/OASIS-6054)

Author: Derek Hammond

CONTRIBUTING.md

@@ -5,21 +5,22 @@ We welcome contributions and feedback! All contributors must sign our [Contribut
 ## Development process
 
 1. Fork the repository and create your branch from master.
-2. Please follow the [commit message guidelines](https://github.com/angular/angular/blob/master/CONTRIBUTING.md#-commit-message-guidelines) for each commit message. 
+2. Please follow the [commit message guidelines](https://github.com/angular/angular/blob/master/CONTRIBUTING.md#-commit-message-guidelines) for each commit message.
 3. Make sure to add tests!
-4. Run `npm run lint` to ensure there are no lint errors.
-5. `git push` your changes to GitHub.
-6. Open a PR from your fork into the master branch of the original repo
-7. Make sure that all unit tests are passing and that there are no merge conflicts between your branch and `master`.
-8. Open a pull request from `YOUR_NAME/branch_name` to `master`.
-9. A repository maintainer will review your pull request and, if all goes well, squash and merge it!
+4. Update relevant `CHANGELOG.md` if users should know about this change.
+5. Run `npm run lint` to ensure there are no lint errors.
+6. `git push` your changes to GitHub.
+7. Open a PR from your fork into the master branch of the original repo
+8. Make sure that all unit tests are passing and that there are no merge conflicts between your branch and `master`.
+9. Open a pull request from `YOUR_NAME/branch_name` to `master`.
+10. A repository maintainer will review your pull request and, if all goes well, squash and merge it!
 
 ## Pull request acceptance criteria
 
-* **All code must have test coverage.** We use Mocha's chai assertion library and Sinon. Changes in functionality should have accompanying unit tests. Bug fixes should have accompanying regression tests.
-  * Tests are located in the `tests.js` file.
-* Please don't change the `package.json` or `VERSION`. We'll take care of bumping the version when we next release.
-* Lint your code with our `npm run lint` before submitting.
+- **All code must have test coverage.** We use Mocha's chai assertion library and Sinon. Changes in functionality should have accompanying unit tests. Bug fixes should have accompanying regression tests.
+  - Tests are located in the `tests.js` file.
+- Please don't change the `package.json` or `VERSION`. We'll take care of bumping the version when we next release.
+- Lint your code with our `npm run lint` before submitting.
 
 ## Style
 
@@ -45,7 +46,7 @@ All contributions are under the CLA mentioned above. For this project, Optimizel
  * See the License for the specific language governing permissions and      *
  * limitations under the License.                                           *
  ***************************************************************************/
- ```
+```
 
 The YEAR above should be the year of the contribution. If work on the file has been done over multiple years, list each year in the section above. Example: Optimizely writes the file and releases it in 2014. No changes are made in 2015. Change made in 2016. YEAR should be “2014, 2016”.