add BrianHicks/elm-benchmark to native whitelist

[BrianHicks]

See #221 for details

[process-bot]

Thanks for the pull request! Make sure it satisfies this checklist. My human colleagues will appreciate it!

Here is what to expect next, and if anyone wants to comment, keep these things in mind.

[evancz]

We talked through the code in video chat. It looks good, exciting stuff!

More generally, the native whitelist is for platform code. So the general rule is that it is only be available to projects under the @elm-lang or @elm-tools organization. That means the surface area between Elm and the target language is as small as possible. This has two major benefits:

1. When Elm targets some language besides JS, the number of libraries that need to be changed is very small. Once the things in official orgs is converted, the whole ecosystem of packages will just work on WebAssembly or x86 or whatever else.

2. This dangerous code can be carefully vetted. That means that there will be O(1) chances for JS mistakes as opposed to O(n) in the size of the package ecosystem.

This is the current conception of the native whitelist, but there are some side considerations:

1. When the native whitelist was created, it wasn't clear exactly which rules would be healthiest for the Elm ecosystem in the long run. So there are some legacy entries on the list that will be phased out over time.

2. There are folks who are collaborating like this who have libraries that are on track to become part of one of the "platform" organizations. This includes the array exploration. I think it's fair to put this benchmarking library in that category. Perhaps we can find a way to extract out the core functionality for benchmarking in a very minimal way, but I think it's reasonable to have this as a starting point.