Improve robustness of _t() key checks

[GuySartorelli]

silverstripe/silverstripe-framework#11603 was raised in part because there was a scenario where weird variable nonsense turned a key that would ordinarily be ignored (because it's dynamic) into a key that has a period at the end.

That case is being ignored now - but it means if we have a period at the end of a _t() key it'll be ignored, instead of telling us to fix it.

TranslationFunctionRule is intended to catch invalid keys, but it wouldn't catch a scenario where both:

• The dev forgets to add the first period
• The dev accidentally adds a period at the end of the key

It's an edge case, but we should avoid it.

Acceptance Criteria

• Keys cannot start with a period
• Keys cannot end with a period