use boringssl's upstream directly; removes need for our fork and committed generated files

[spoonincode]

When we added boringssl the only way to integrate it without requiring golang was to commit generated files in to the repository. This is quite the horror to me because it makes it difficult for anyone (including ourselves) to check that the generated files haven't been tampered with by whoever committed them. To try and mitigate that, the repo we store the generated files in (https://github.com/AntelopeIO/boringssl-build) contains a workflow to double check the committed files by generating them itself using golang etc. Still very undesirable though.

A handful of months ago boringssl modified their build structure so that golang was no longer required to use the cmake files. And, astonishingly, it Just Works even in our use case.

This is a big deal. It makes it trivial for anyone (including ourselves) to verify that we're using upstream verbatim. I think it's worth doing the upgrade.

I eyeballed the commit titles (and it some cases the commit contents) from our prior pinned commit of a1843d6. Didn't see anything alarming (anything that could affect our usage). Certainly could be worth another set of eyeballs skimming over the commit title history (https://boringssl.googlesource.com/boringssl/+log).

Didn't see any differences in our benchmark application (the merkle test is a bit persnickety for me to get consistent results though unless I increase the number of runs substantially, since these otherwise run very few runs)

[linh2931]

Scanned the commit history list. It seems fine.

[ericpassmore]

Note:start
category: Chores
component: Internal
summary: Pull boringssl submodule directly from upstream source.
Note:end