The default token pattern in CountVectorizer breaks Indic sentences into non-sensical tokens

### Describe the bug

The default `token_pattern` in `CountVectorizer` is `r"(?u)\b\w\w+\b"` which tokenizes Indic texts in a wrong way - breaks whitespace tokenized words into multiple chunks and even omits several valid characters. The resulting vocabulary doesn't make any sense !

Is this the expected behaviour?

Sample code is pasted in the sections below

### Steps/Code to Reproduce

```
import sklearn
from sklearn.feature_extraction.text import CountVectorizer

tel = ["ప్రధానమంత్రిని కలుసుకున్నారు"]
hin = ["आधुनिक मानक हिन्दी"]
eng = ["They met the Prime Minister"]

cvect = CountVectorizer(
    ngram_range=(1, 1),
    max_features=None,
    min_df=1,
    strip_accents=None,
)
cvect.fit(tel + hin + eng)
print(cvect.vocabulary_)
```

### Expected Results

```
{'ప్రధానమంత్రిని': 9, 'కలుసుకున్నారు': 8, 'आधुनिक': 5, 'मानक': 6, 'हिन्दी': 7, 'they': 4, 'met': 0, 'the': 3, 'prime': 2, 'minister': 1}
```

### Actual Results

```
{'రధ': 9, 'నమ': 8, 'కల': 7, 'आध': 5, 'नक': 6, 'they': 4, 'met': 0, 'the': 3, 'prime': 2, 'minister': 1}
```


### Versions

```
System:
    python: 3.11.10 (main, Oct  3 2024, 07:29:13) [GCC 11.2.0]
executable: miniconda3/envs/lolm/bin/python
   machine: Linux-6.1.0-25-amd64-x86_64-with-glibc2.36

Python dependencies:
      sklearn: 1.5.2
          pip: 24.2
   setuptools: 75.1.0
        numpy: 1.26.0
        scipy: 1.14.1
       Cython: None
       pandas: 2.2.3
   matplotlib: 3.9.2
       joblib: 1.4.2
threadpoolctl: 3.5.0

Built with OpenMP: True

threadpoolctl info:
       user_api: blas
   internal_api: mkl
    num_threads: 1
         prefix: libmkl_rt
       filepath: miniconda3/envs/lolm/lib/libmkl_rt.so.2
        version: 2023.1-Product
threading_layer: gnu

       user_api: openmp
   internal_api: openmp
    num_threads: 1
         prefix: libgomp
       filepath: miniconda3/envs/lolm/lib/libgomp.so.1.0.0
        version: None
```

COMMENT:
Looking at what characters are in the string and which category they belong to, I think I now understand why the string gets split up in weird ways:
```python
for c in tel:
    print(f"'{c}' is in category '{unicodedata.category(c)}' and is called '{unicodedata.name(c)}'")
```
Prints out:
```
'ప' is in category 'Lo' and is called 'TELUGU LETTER PA'
'్' is in category 'Mn' and is called 'TELUGU SIGN VIRAMA'
'ర' is in category 'Lo' and is called 'TELUGU LETTER RA'
'ధ' is in category 'Lo' and is called 'TELUGU LETTER DHA'
'ా' is in category 'Mn' and is called 'TELUGU VOWEL SIGN AA'
'న' is in category 'Lo' and is called 'TELUGU LETTER NA'
'మ' is in category 'Lo' and is called 'TELUGU LETTER MA'
'ం' is in category 'Mc' and is called 'TELUGU SIGN ANUSVARA'
'త' is in category 'Lo' and is called 'TELUGU LETTER TA'
'్' is in category 'Mn' and is called 'TELUGU SIGN VIRAMA'
'ర' is in category 'Lo' and is called 'TELUGU LETTER RA'
'ి' is in category 'Mn' and is called 'TELUGU VOWEL SIGN I'
'న' is in category 'Lo' and is called 'TELUGU LETTER NA'
'ి' is in category 'Mn' and is called 'TELUGU VOWEL SIGN I'
' ' is in category 'Zs' and is called 'SPACE'
'క' is in category 'Lo' and is called 'TELUGU LETTER KA'
'ల' is in category 'Lo' and is called 'TELUGU LETTER LA'
'ు' is in category 'Mc' and is called 'TELUGU VOWEL SIGN U'
'స' is in category 'Lo' and is called 'TELUGU LETTER SA'
'ు' is in category 'Mc' and is called 'TELUGU VOWEL SIGN U'
'క' is in category 'Lo' and is called 'TELUGU LETTER KA'
'ు' is in category 'Mc' and is called 'TELUGU VOWEL SIGN U'
'న' is in category 'Lo' and is called 'TELUGU LETTER NA'
'్' is in category 'Mn' and is called 'TELUGU SIGN VIRAMA'
'న' is in category 'Lo' and is called 'TELUGU LETTER NA'
'ా' is in category 'Mn' and is called 'TELUGU VOWEL SIGN AA'
'ర' is in category 'Lo' and is called 'TELUGU LETTER RA'
'ు' is in category 'Mc' and is called 'TELUGU VOWEL SIGN U'
```

Characters in the `Mn` category get treated as "not word characters". Maybe this is a case where the default pattern doesn't make sense and you need to use a custom pattern. If this is common we should add some documentation or an example to help others figure this out

Labels: Bug