harness: Fix race condition when torn down during the handling of a non-serialized query or event

It's possible and normal to tear down a harness while the pipeline is running. At the same time, it's desired for the gst_harness_pad_link_tear_down() function to be synchronous.

This has created the conflict where the main thread may request a harness to be torn down while it's in use or about to be used by a pad in the streaming thread.

The previous implementation of gst_harness_pad_link_tear_down() tried to handle this by taking the stream lock of the harnessed pad and resetting all the pad functions while holding it. That approach was however insufficient to handle the case where a non-serialized event or query is being handled or about to be handled in a different thread.

This edge case was one race condition behind the flakes in the flvmux check tests -- the rest being covered by #2803.

This patch fixes the problem by adding an intermediate ref-counted object, GstHarnessLink, which replaces the usage of the HARNESS_KEY association. GstHarnessLink allows the pad functions such as event, query and chain to borrow a reference to GstHarness and more importantly, to lock the GstHarnessLink during their usage to block (delay) its destruction until no users are left, and guarantee that any future user will not receive an invalid GstHarness handle past its destruction.