Stable order of synthesized bridges.

In some cases when several bridge methods are generated, their order
is undetermenistic. For example for class ClassLowerWithContext in the
following example

```
interface IrElement
class IrClassContext

interface IrElementVisitor<out R, in D> {
    fun visitElement(element: IrElement, data: D): R
}

interface IrElementTransformer<in D> : IrElementVisitor<IrElement, D> {
    override fun visitElement(element: IrElement, data: D): IrElement =
            element.also { throw RuntimeException() }
}

abstract class ClassLowerWithContext : IrElementTransformer<IrClassContext?>
```

kotlin compiler synthesizes two additional bridges:

  public IrElement visitElement(IrElement, IrClassContext);
  [bridge] public Object visitElement(IrElement, Object);
  [bridge] public IrElement visitElement(IrElement, Object);

Unfortunately the behavior is not deterministic and not easy to reproduce.

compiler/backend-common/src/org/jetbrains/kotlin/backend/common/bridges/bridges.kt

@@ -56,7 +56,7 @@ fun <Function : FunctionHandle, Signature> generateBridges(
 
     val implementation = findConcreteSuperDeclaration(function)
 
-    val bridgesToGenerate = findAllReachableDeclarations(function).mapTo(HashSet<Signature>(), signature)
+    val bridgesToGenerate = findAllReachableDeclarations(function).mapTo(LinkedHashSet<Signature>(), signature)
 
     if (fake) {
         // If it's a concrete fake override, some of the bridges may be inherited from the super-classes. Specifically, bridges for all
@@ -85,7 +85,7 @@ fun <Function : FunctionHandle> findAllReachableDeclarations(function: Function)
     }
     @Suppress("UNCHECKED_CAST")
     DFS.dfs(listOf(function), { it.getOverridden() as Iterable<Function> }, collector)
-    return HashSet(collector.result())
+    return LinkedHashSet(collector.result())
 }
 
 /**