- quote the RFC
- add a link to the RFC
- fix markdown

RFC 4291 is a little unclear about what is a unicast link local address.
According to section 2.4, the entire fe80::/10 range is reserved for
these addresses, but section 2.5.3 defines a stricter format for such
addresses.

After a discussion[0] is has been decided to add a different method for
each definition, so this commit:

  - renames is_unicast_link_local() into is_unicast_link_local_strict()
  - relaxed the check in is_unicast_link_local()

[0]: rust-lang#27709 (comment)

As per @therealbstern's comment[0]:

The implementation of Ipv4::is_global is not complete, according to the
IANA IPv4 Special-Purpose Address Registry.

        - It compares the address to 0.0.0.0, but anything in 0.0.0.0/8
          should not be considered global.
                - 0/8 is not global and is currently forbidden because
                  some systems used to treat it as the local network.
                - The implementation of Ipv4::is_unspecified is correct.
                  0.0.0.0 is the unspecified address.
        - It does not examine 100.64.0.0/10, which is "Shared Address
          Space" and not global.
        - Ditto 192.0.0.0/24 (IETF Protocol Assignments), except for
          192.0.0.9/32 and 192.0.0.10/32, which are carved out as
          globally reachable.
        - 198.18.0.0/15 is for "Benchmarking" and should not be globally
          reachable.
        - 240.0.0.0/4 is reserved and not currently reachable

Ipv4addr::is_global() previously considered 0/8 was global, but has
now been fixed, so these tests needed to be fixed as well.

Ipv6Addr::is_unicast_global() now returns `true` for unicast site
local addresses, since they are deprecated.

also add test to Ipaddr, making sure that these addresses are not
global.

Also add tests to IpAddr to make sure these addresses are not global.

Also add tests to IpAddr for make sure these addresses are not global
or multicast.

site-local addresses are deprecated, so we should warn users about it.

See @the8472 comment's on Github:
rust-lang#60145 (comment)

> I don't think is_reserved including ranges marked for future use is
> a good idea since those future uses may be realized at at some point
> and then old software with is_reserved filters may have false
> positives. This is not a hypothetical concern, such issues have been
> encountered before when IANA assigned previously reserved /8 address
> blocks.