[0.13.10] Always invalidate API when return type is a value class

The previous approach to value class API (introduced by sbt/sbt#2261 and
refined by sbt/sbt#2413 and sbt/sbt#2414) was to store both unerased and
erased signatures so that changes to value classes forced recompilations.
This is no longer necessary thanks to sbt#87: if a class type is
used, then it becomes a dependency of the current class and its name is
part of the used names of the current class. Since the name hash of a
class changes if it stops or start extending AnyVal, this is enough to
force recompilation of anything that use a value class type. If the
underlying type of a value class change, its name hash doesn't change,
but the name hash of <init> change and since every class uses the name
<init>, we don't need to do anything special to trigger recompilations
either.

The previous approach to value class API (introduced by sbt/sbt#2261 and
refined by sbt/sbt#2413 and sbt/sbt#2414) was to store both unerased and
erased signatures so that changes to value classes forced recompilations.
This is no longer necessary thanks to sbt#87: if a class type is
used, then it becomes a dependency of the current class and its name is
part of the used names of the current class. Since the name hash of a
class changes if it stops or start extending AnyVal, this is enough to
force recompilation of anything that use a value class type. If the
underlying type of a value class change, its name hash doesn't change,
but the name hash of <init> change and since every class uses the name
<init>, we don't need to do anything special to trigger recompilations
either.

The previous approach to value class API (introduced by sbt/sbt#2261 and
refined by sbt/sbt#2413 and sbt/sbt#2414) was to store both unerased and
erased signatures so that changes to value classes forced recompilations.
This is no longer necessary thanks to sbt#87: if a class type is
used, then it becomes a dependency of the current class and its name is
part of the used names of the current class. Since the name hash of a
class changes if it stops or start extending AnyVal, this is enough to
force recompilation of anything that uses a value class type. If the
underlying type of a value class change, its name hash doesn't change,
but the name hash of <init> change and since every class uses the name
<init>, we don't need to do anything special to trigger recompilations
either.

This is a backport of sbt/zinc#95

The previous approach to value class API (introduced by sbt#2261 and
refined by sbt#2413 and sbt#2414) was to store both unerased and
erased signatures so that changes to value classes forced
recompilations.
This is no longer necessary thanks to sbt#2523: if a class type is
used, then it becomes a dependency of the current class and its name is
part of the used names of the current class. Since the name hash of a
class changes if it stops or start extending AnyVal, this is enough to
force recompilation of anything that uses a value class type. If the
underlying type of a value class change, its name hash doesn't change,
but the name hash of `<init>` changes and since every class uses the name
`<init>`, we don't need to do anything special to trigger recompilations
either.

This is a backport of sbt/zinc#95

The previous approach to value class API (introduced by sbt#2261 and
refined by sbt#2413 and sbt#2414) was to store both unerased and
erased signatures so that changes to value classes forced
recompilations.
This is no longer necessary thanks to sbt#2523: if a class type is
used, then it becomes a dependency of the current class and its name is
part of the used names of the current class. Since the name hash of a
class changes if it stops or start extending AnyVal, this is enough to
force recompilation of anything that uses a value class type. If the
underlying type of a value class change, its name hash doesn't change,
but the name hash of `<init>` changes and since every class uses the name
`<init>`, we don't need to do anything special to trigger recompilations
either.

This is a backport of sbt/zinc#95

The previous approach to value class API (introduced by sbt#2261 and
refined by sbt#2413 and sbt#2414) was to store both unerased and
erased signatures so that changes to value classes forced
recompilations.
This is no longer necessary thanks to sbt#2523: if a class type is
used, then it becomes a dependency of the current class and its name is
part of the used names of the current class. Since the name hash of a
class changes if it stops or start extending AnyVal, this is enough to
force recompilation of anything that uses a value class type. If the
underlying type of a value class change, its name hash doesn't change,
but the name hash of `<init>` changes and since every class uses the name
`<init>`, we don't need to do anything special to trigger recompilations
either.

This is a backport of sbt/zinc#95

The previous approach to value class API (introduced by sbt#2261 and
refined by sbt#2413 and sbt#2414) was to store both unerased and
erased signatures so that changes to value classes forced
recompilations.
This is no longer necessary thanks to sbt#2523: if a class type is
used, then it becomes a dependency of the current class and its name is
part of the used names of the current class. Since the name hash of a
class changes if it stops or start extending AnyVal, this is enough to
force recompilation of anything that uses a value class type. If the
underlying type of a value class change, its name hash doesn't change,
but the name hash of `<init>` changes and since every class uses the name
`<init>`, we don't need to do anything special to trigger recompilations
either.

This is a backport of sbt/zinc#95

The previous approach to value class API (introduced by sbt#2261 and
refined by sbt#2413 and sbt#2414) was to store both unerased and
erased signatures so that changes to value classes forced
recompilations.
This is no longer necessary thanks to sbt#2523: if a class type is
used, then it becomes a dependency of the current class and its name is
part of the used names of the current class. Since the name hash of a
class changes if it stops or start extending AnyVal, this is enough to
force recompilation of anything that uses a value class type. If the
underlying type of a value class change, its name hash doesn't change,
but the name hash of `<init>` changes and since every class uses the name
`<init>`, we don't need to do anything special to trigger recompilations
either.

This is a backport of sbt/zinc#95

The previous approach to value class API (introduced by sbt#2261 and
refined by sbt#2413 and sbt#2414) was to store both unerased and
erased signatures so that changes to value classes forced
recompilations.
This is no longer necessary thanks to sbt#2523: if a class type is
used, then it becomes a dependency of the current class and its name is
part of the used names of the current class. Since the name hash of a
class changes if it stops or start extending AnyVal, this is enough to
force recompilation of anything that uses a value class type. If the
underlying type of a value class change, its name hash doesn't change,
but the name hash of `<init>` changes and since every class uses the name
`<init>`, we don't need to do anything special to trigger recompilations
either.

This is a backport of sbt/zinc#95

The previous approach to value class API (introduced by sbt#2261 and
refined by sbt#2413 and sbt#2414) was to store both unerased and
erased signatures so that changes to value classes forced
recompilations.
This is no longer necessary thanks to sbt#2523: if a class type is
used, then it becomes a dependency of the current class and its name is
part of the used names of the current class. Since the name hash of a
class changes if it stops or start extending AnyVal, this is enough to
force recompilation of anything that uses a value class type. If the
underlying type of a value class change, its name hash doesn't change,
but the name hash of `<init>` changes and since every class uses the name
`<init>`, we don't need to do anything special to trigger recompilations
either.

This is a backport of sbt/zinc#95

The previous approach to value class API (introduced by sbt#2261 and
refined by sbt#2413 and sbt#2414) was to store both unerased and
erased signatures so that changes to value classes forced
recompilations.
This is no longer necessary thanks to sbt#2523: if a class type is
used, then it becomes a dependency of the current class and its name is
part of the used names of the current class. Since the name hash of a
class changes if it stops or start extending AnyVal, this is enough to
force recompilation of anything that uses a value class type. If the
underlying type of a value class change, its name hash doesn't change,
but the name hash of `<init>` changes and since every class uses the name
`<init>`, we don't need to do anything special to trigger recompilations
either.

This is a backport of sbt/zinc#95

The previous approach to value class API (introduced by sbt#2261 and
refined by sbt#2413 and sbt#2414) was to store both unerased and
erased signatures so that changes to value classes forced
recompilations.
This is no longer necessary thanks to sbt#2523: if a class type is
used, then it becomes a dependency of the current class and its name is
part of the used names of the current class. Since the name hash of a
class changes if it stops or start extending AnyVal, this is enough to
force recompilation of anything that uses a value class type. If the
underlying type of a value class change, its name hash doesn't change,
but the name hash of `<init>` changes and since every class uses the name
`<init>`, we don't need to do anything special to trigger recompilations
either.

This is a backport of sbt/zinc#95

The previous approach to value class API (introduced by sbt#2261 and
refined by sbt#2413 and sbt#2414) was to store both unerased and
erased signatures so that changes to value classes forced
recompilations.
This is no longer necessary thanks to sbt#2523: if a class type is
used, then it becomes a dependency of the current class and its name is
part of the used names of the current class. Since the name hash of a
class changes if it stops or start extending AnyVal, this is enough to
force recompilation of anything that uses a value class type. If the
underlying type of a value class change, its name hash doesn't change,
but the name hash of `<init>` changes and since every class uses the name
`<init>`, we don't need to do anything special to trigger recompilations
either.

This is a backport of sbt/zinc#95

The previous approach to value class API (introduced by sbt#2261 and
refined by sbt#2413 and sbt#2414) was to store both unerased and
erased signatures so that changes to value classes forced
recompilations.
This is no longer necessary thanks to sbt#2523: if a class type is
used, then it becomes a dependency of the current class and its name is
part of the used names of the current class. Since the name hash of a
class changes if it stops or start extending AnyVal, this is enough to
force recompilation of anything that uses a value class type. If the
underlying type of a value class change, its name hash doesn't change,
but the name hash of `<init>` changes and since every class uses the name
`<init>`, we don't need to do anything special to trigger recompilations
either.

The previous approach to value class API (introduced by sbt/sbt#2261 and
refined by sbt/sbt#2413 and sbt/sbt#2414) was to store both unerased and
erased signatures so that changes to value classes forced recompilations.
This is no longer necessary thanks to scala#87: if a class type is
used, then it becomes a dependency of the current class and its name is
part of the used names of the current class. Since the name hash of a
class changes if it stops or start extending AnyVal, this is enough to
force recompilation of anything that uses a value class type. If the
underlying type of a value class change, its name hash doesn't change,
but the name hash of <init> change and since every class uses the name
<init>, we don't need to do anything special to trigger recompilations
either.

The previous approach to value class API (introduced by sbt/sbt#2261 and
refined by sbt/sbt#2413 and sbt/sbt#2414) was to store both unerased and
erased signatures so that changes to value classes forced recompilations.
This is no longer necessary thanks to scala#87: if a class type is
used, then it becomes a dependency of the current class and its name is
part of the used names of the current class. Since the name hash of a
class changes if it stops or start extending AnyVal, this is enough to
force recompilation of anything that uses a value class type. If the
underlying type of a value class change, its name hash doesn't change,
but the name hash of <init> change and since every class uses the name
<init>, we don't need to do anything special to trigger recompilations
either.

Rewritten from sbt/zinc@1e7e99e