stats: inconsistent handling of multiple consecutive dots in stat-names produced via join vs direct encoding

You can create a multi-segment stat-name by directly encoding it into the table, or by joining multiple existing stat names.

When you encode directly, you can wind up with multiple consecutive dots. When you construct by joining, you can't. The testcase in this commit illustrates the problem:

https://github.com/jmarantz/envoy/commit/6e7367c522c2fb5e77bb1d59cb54817e039bd9c3

```
TEST_P(StatNameTest, TestIgnoreTrailingDots) {
EXPECT_EQ("foo.bar", encodeDecode("foo.bar."));
EXPECT_EQ("foo.bar", encodeDecode("foo.bar..."));
EXPECT_EQ("foo..bar", encodeDecode("foo..bar"));
EXPECT_EQ("foo...bar", encodeDecode("foo...bar"));

StatNamePool pool(*table_);
SymbolTable::StoragePtr joined = table_->join({makeStat("a"), makeStat(""), makeStat("b")});
EXPECT_EQ("a..b", table_->toString(StatName(joined.get()))); // FAILS, will be "a.b".

EXPECT_EQ("", encodeDecode("."));
EXPECT_EQ("", encodeDecode(".."));
}
```