Handle multiple lightweight tabs on a commit

[zjs]

The GitHub release process creates lightweight tags, which do not have
associated metadata such as date information. This causes git describe
to fall back to lexicographic ordering to break the tie between two or
more candidate tags when multiple exist on a given commit.

When building a new RC build to pick up a new RC build of a component,
we wind up with multiple tags on a single commit in vic-product (since
we simply need to do a new build of the same commit to pick up the new
build of the changed component).

When we are performing a tag build, we expect the corresponding tag to
be used— which may not always be the tag that would be selected by git
describe. Ensure we use the expected tag falling back to git describe
only if the $DRONE_TAG variable is not set.

This should preserve the current behavior for non-tag builds (and when
building outside of our CI/CD environment) and enable continued use of
lightweight tags (while we explore the impacts of using annotated tags
on our CI/CD logic).

---

VIC Appliance Checklist:

• Up to date with master branch
• Added tests
• Considered impact to upgrade
• Tests passing
• Updated documentation
• Impact assessment checklist

If this is a feature or change to existing functionality, consider areas of impact with the Impact
Assessment Checklist

[hickeng]

I like this - it makes it consistent with the build number and allows override on the CLI for testing tag behaviour if needed.
We need to find a way to de-duplicate this build logic with the vic repo.