GlTabsBehavior - Add `hash` support

What / Why

Follow up from conversations between @markrian and I here: !88577 (comment 961174169)

As part of the Pajamas cleanup efforts we have been migrating HAML tabs from LinkedTabs => GlTabsBehavior.

A noticeable change between the two is GlTabsBehavior doesn't support hash updating out of the box. With LinkedTabs this was done via manipulating the #anchor of the path. Additionally this supported "loading" a specific tab via the hash. Not having this functionality makes a bit more challenging to refactor and requires some additional code included with importing.

Live examples can be found with:

1. Milestones: https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/assets/javascripts/milestones/milestone.js#L10-30
2. Group Usage Quotas - https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/assets/javascripts/pages/groups/usage_quotas/index.js#L10-39
3. Profile Usage Quotas - https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/assets/javascripts/pages/profiles/usage_quotas/index.js#L8-37

Additional Issues

There is an additional issue when it comes to migrating from LinkedTabs to GlTabsBehavior in that when adding the custom anchor tags it causes our default "anchor tag" jumping to occur. This can be jarring when trying to cycle through tabs. An example of this behavior can be seen here:

Page Jumping

@markrian noted in regards to why the jumping doesn't occur in the LinkedTabs implementation:

Looking at it now, I think this condition is evaluating to false, since the click event bubbled to body before LinkedTabs set the location hash to the new tab's value. That seems like a lucky coincidence to me, but perhaps it was designed that way 🤷 If so, maybe that's an approach to take.

Proposal

1. Add an optional parameter to the GlTabsBehavior constructor to update the anchor tag of the path.
2. Attempt to replicate the hash logic from LinkedTabs to avoid the jumping behavior currently occurring.