implied: fix a bug with borrowed implications

implied: fix a bug with borrowed implications

This bug was, of course, found parsing real code.  Then I built
sm_implied19.c as a test case.  Originally, it printed that "vbus"
was 0.  After this patch is applied it prints that "vbus" is s32min-s32max.

I'm 80% sure that this fix is the correct approach.

This bug has to do with borrowed implications.  When we merge an sm_state
then we get ->left and ->right pointers.  Then when we assign an int to
an int, for example "a = b;"  we want to preserve that history so we can
figure out the implications of "if (a == 42) "later using the merge
history of b.  So when you look at the ->left and ->right pointers the
variable can actually be different than the variable you started out with.

Pools are a collection of states before a merge.  They are linked by ->left
and ->right sm_states which have a ->pool pointer.  When we start out the
->left and ->right states have the same estate ->state as they do in the
pool that they point to.  But later, when we're figuring out the implications
of stuff we start mangling the ->left and ->right pointers so now they
might be a subset of the estate in the pool.

The problem here (I think) is that we're mangling borrowed states.  And the
fix for that is to clone the sm_states before mangling them so we don't
affect the other users.  I also changed the ->name and ->sym because why
not?

I wish that I were more certain of this fix but it definitely fixes my test
case.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>