link cache: remove AF_UNSPEC check in rtnl_get_link and rtnl_get_link_by_name

This patch reverts back the AF_UNSPEC check introduced by AF_BRIDGE
changes at http://lists.infradead.org/pipermail/libnl/2012-November/000796.html

After the addition of AF_BRIDGE support, link cache can now contain objects of
type AF_BRIDGE. To make sure existing api's did not return AF_BRIDGE objects
and surprise existing callers, I introduced the check for AF_UNSPEC.

But from what Andy Wang reported, rtnl_link_get_by_name returns the first
link object with matching ifindex and that could have not only been AF_UNSPEC
but also of family AF_INET6. And his app always got an AF_INET6 object prior
to the patch that introduced the AF_UNSPEC check.

I could just add AF_INET6 family check along with AF_UNSPEC in the apis and that
should work well.

But thinking about it some more, removing the AF_UNSPEC change seems to be safer at
this point. That way this api will retain its semantics and return the first object
with matching ifindex. It could be of any supported family. The user will know if the
cache contains bridge objects, because they are available only with the cache flag
NL_CACHE_AF_ITER. Besides, if new users want to search for a specific object,
nl_cache_find is a better option.

Reported-by: Andy Wang <Andy.Wang@watchguard.com>
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Signed-off-by: Thomas Graf <tgraf@suug.ch>