Overall I'm in favour of this.
On the one hand, this is a problem that every program that links against system libraries has to tackle, and we do it all the time using if #available for libraries like Foundation. In that sense it's not entirely unreasonable to tell those system administrators that they have to update the OS to patch security holes or take advantage of newer features like HTTP2/3.
On the other hand, it sounds like libssl has been a bit sloppy about API and ABI compatibility. In the absence of a stable alternative library, it makes sense to bundle our own implementation.
I would love to see us expose a public, Swift interface to the SSL/crypto functions one day, but that's a whole other thing.
I'm a bit concerned about how narrowly BoringSSL might be focused on their own needs and how closed it is to external needs/contributions. We can only try it and see - we'd still have the option to change the implementation we use if problems arise.
Also - Apple has open-sourced recent versions of many crypto frameworks (CommonCrypto, Security.framework, coretls). I'm not exactly sure how they all fit together, but is there not a complete/nearly-complete implementation there which we could use? I guess that interface is stable enough that we could create a nice Swift wrapper for it.