Use installed module stem for .so soname

So that the SONAME will match the actual installed name. This allows two
shared libraries (with different LOCAL_MODULE names) to be built with
the same name, but in different locations. So to partially emulate
Soong's vendor_available, you could define:

  include $(CLEAR_VARS)
  LOCAL_MODULE := libmyutils
  ...
  include $(BUILD_SHARED_LIBRARY)

  include $(CLEAR_VARS)
  LOCAL_MODULE := libmyutils_vendor
  LOCAL_VENDOR_MODULE := true
  LOCAL_INSTALLED_MODULE_STEM := libmyutils.so
  ...
  include $(BUILD_SHARED_LIBRARY)

All of the users would need to explicitly use libmyutils vs
libmyutils_vendor based on how their runtime lookup paths are going to
work, but it will install into both places:

  /system/lib/libmyutils.so
  /vendor/lib/libmyutils.so

Bug: 38225484
Test: Example similar to above, ensure DT_NEEDED / DT_SONAME are correct
Test: multiproduct_kati to verify the only module this changes on
      master is libart_fake
Change-Id: Ifa4b8adff50d8b5a754c70ce8e865b05f9889c6c

core/dynamic_binary.mk

@@ -23,7 +23,7 @@ intermediates := $(call local-intermediates-dir,,$(LOCAL_2ND_ARCH_VAR_PREFIX))
 # The basename of this target must be the same as the final output
 # binary name, because it's used to set the "soname" in the binary.
 # The includer of this file will define a rule to build this target.
-linked_module := $(intermediates)/LINKED/$(my_built_module_stem)
+linked_module := $(intermediates)/LINKED/$(notdir $(my_installed_module_stem))
 
 ALL_ORIGINAL_DYNAMIC_BINARIES += $(linked_module)