This PR aims at fixing a performance pitfall in the current implementation of Guid initializers.
Both Guid(String input) and Guid.fromMac(String input) perform a test on the input String through _fromString and _fromMacString methods respectively. The test is operated using a regular expression to catch the expected number of hex couples and decode them to a list of bytes:

final RegExp regex = new RegExp('[0-9a-f]{2}');

The problem with this approach is the performance cost of performing a Regex every time a Guid is created either by a client application (which might be negligible) or by flutter_blue itself (which hits the Guid initializer a lot of times).
Even if Dart is not particularly slow on regex, flutter_blue uses the Guid initializers very frequently, especially in those scenarios when a BT characteristic is read/written/indicated at short intervals.

To verify this behavior I profiled a small application that reads from a characteristic about 2 times in a second.

As you can see from the above flame chart, a lot of time is spent in Guid._fromString method.

In this PR i modified both _fromString and _fromMacString methods not to use any regex check but instead simply decode the input string to hex bytes after all non-hex characters are stripped from it.
The procedure to remove non-hex character has also been improved to run in a single pass, instead of three consecutive .replaceAll calls.
All the preexisting checks regarding the expected length of bytes are still left intact, all the tests in guid_tests.dart are passing.

Profiling the same application after the optimizations yields the following flame chart:

As you can see, cpu time is now better distributed across framework tasks and the disproportion of Guid methods is no longer perceivable.