hashmapStats allocated unconditionally regardless of StatsEnabled

## Description

In v3.1.0, `hashmapStats` was added to each shard in `initNewShard`:

```go
return &cacheShard{
hashmap: make(map[uint64]uint32, config.initialShardSize()),
hashmapStats: make(map[uint64]uint32, config.initialShardSize()), // always allocated
...
}
```

However, `hashmapStats` is only read/written when `StatsEnabled: true`. `DefaultConfig` sets `StatsEnabled: false`, so the vast majority of users never use stats — yet they pay the full memory cost of `hashmapStats` at startup.

## Memory impact

The allocation cost per shard is `initialShardSize() * sizeof(map entry)`. With `DefaultConfig`:
- `MaxEntriesInWindow = 600_000`, `Shards = 1024`
- `initialShardSize = 600_000 / 1024 = 585` entries per shard
- Each map pre-allocates ~17.5 KB of buckets

For a setup with many independent BigCache instances (e.g. 16), the unconditional `hashmapStats` allocation adds:

```
16 instances × 1024 shards × ~17.5 KB = ~286 MiB
```

This memory is entirely wasted when `StatsEnabled: false`.

## Expected behavior

`hashmapStats` should only be allocated when `StatsEnabled: true`:

```go
if config.StatsEnabled {
shard.hashmapStats = make(map[uint64]uint32, config.initialShardSize())
}
```

## Suggested fix

Allocate `hashmapStats` conditionally in `initNewShard`, and guard all reads/writes to it with a `StatsEnabled` check (they likely already are, given the field only makes sense with stats on).

## Version

v3.1.0 (not present in v3.0.2)