Formal request to unify ⺮ component

I would like to formally request to unify ⺮ component to JP form for all regions.

>I would like to suggest to consider unifying the ⺮ radical for all regions, using the form that the dots are connected to the horizontal line above. This applies to both the Sans and Serif version.
>
>Currently, the dots of the ⺮ component doesn't join the horizontal stoke above ~~just for TW variant. The forthcoming HK variant will probably follow suit.~~ [Editor: for TW and HK variant.]
>
>⺮ is a variant of 竹 which vertical strokes are essentially connected to the horizontal strokes. There isn't a "must" to make it disjointed. A joined form won't confuse user in any way. It doesn't conflict with other component of different origin. The stroke count and order don't change. So I inclined to believe that it doesn't result in a violation of the regional standard (it's just like writing the dot closer to the horizontal line).
*(Quoted from @/tamcy at https://github.com/adobe-fonts/source-han-sans/issues/182#issuecomment-365598683)*

## 國字標準字體 does not specify ⺮ should be disconnected
There is **no evidence** that ⺮ component is specifically required to be disconnected in 國字標準字體 or in any of the official Taiwan MOE documents.
The demonstrated ⺮ is a Regular script font, which is different from printed Ming/Song/Hei fonts for all other regions.
Screenshot are as follow:

> While I cannot suggest changes to resemble another commercial typeface, for the sake of unifying components, I have to give a reference. This reference is Hiragino Sans CNS, which was updated to completely follow Taiwan MOE standards on macOS 12 Monterey after many years of being an incomplete typeface with a mix of Japanese and mainland China glyph shapes. Basically put, the 竹 component in Hiragino Sans CNS is exactly the same as the GB (China) and the Japanese version.
> 
*(Quoted from @/Marcus98T at https://github.com/adobe-fonts/source-han-sans/issues/326)*

>Using a joined version of ⺮ can:
> * frees up a glyph spaces for something more meaningful.
> * reduces chance of discrepancies when viewing articles with characters outside the TW/HK supported range.
> * creates a more pleasant reading experience because of less "noises" in a glyph. The disjoint version doesn't only not help but can sometimes disturb viewer's eyes in certain circumstances, like 箔:
> 
*(Quoted from @/tamcy at https://github.com/adobe-fonts/source-han-sans/issues/182#issuecomment-365598683)*

## Action to take

1. After a basic check, it is determined that at least 200 glyphs from TW can be removed if this request is accepted.
(Only checked with TW version for now)
```
㗛㗳㘉䇛䇭䇹䈑䈣䉀䉪䉶劄匴噬囖幯憡撘攥橁檱櫡潷澨瀄竺竻竽竿笄笅笆笈笋笎笏笐笑笔笘笙笛笞笠笢笣笤笥符笧笨笩笪笫第笮笰笱笲笳笴笵笸笹笻筀筃筅筆筇筈筊筌筍筏筐筒答筕策筘筡筢筤筥筦筧筩筬筭筮筯筰筱筴筶筸筻箄箅箇箈箊箋箌箍箏箑箒箔箕箖算箘箙箚箝管箤箮箯箱箲箴箵箹節篁範篅篆篊篋篎篐篔篕篙篛篜篝篡篣篤篧篨篩篰篸篹篺篼篾簀簁簂簃簆簌簍簎簑簒簕簛簜簞簟簠簡簢簣簥簦簨簫簬簭簰簳簸簹簼簽簾籀籃籄籇籉籌籍籖籛籜籟籣籤籥籦籪籫籮籰籲纂譗鏼鱵
```

2. A few discrepency between glyphs which if resolved might add or remove some glyphs:
```
篏簐笊笟箛
```

3. And at least 90 glyphs in the BMP which need modification of TW glyph (not counting non-BMP HKSCS characters).
```
䇯䉠竼竾笀笉笌笒笓笚笝笭笯筂等筋筎筑筠筲筳筵筷箎箐箜箠箢箬箭箷箾篇築篌篚篟篠篥篦篪篫篬篱篲篳篴篷篻篽簅簇簉簋簏簙簧簩簪簵簷籈簻簿籂籅籊籐籑籓籔籗籙籚籝籠籧籩籬籭籯艞遾笁筄筣箂箣篘篢篿簊簝
```
Light blue are glyphs with only TW/HK, red are characters to take note (筳 might be modified for CN if https://github.com/adobe-fonts/source-han-sans/issues/327 is resolved, 籐 is difference in 氺), and green is already conforming to suggestion of this issue (reported in https://github.com/adobe-fonts/source-han-sans/issues/362).

Among those, these can be restored from v1 JP: `笁笚笝筄筣箂箣篘篢篻(HK)篿簊簝簵`

4. 46 non-BMP glyphs from HKSCS need to be modified too:
```
𠑥𠠬𠿫𡠨𢞖𢴈𢶠𣠺𤄙𤅄𤅕𤨤𤪔𤪱𤴆𤺥𥋘𥫩𥭴𥮉𥮳𥮴𥯆𥯤𥯨𥰁𥰆𥰡𥱊𥱋𥱥𥲑𥲤𥳀𥳁𥳾𥴠𥴰𥵃𥶙𥶹𥸎𨘥𨘻𨰉𨰝
```

This will be a hard request to accept, but with the benefit of 210 free-up CIDs, visually more pleasing characters, while still maintaining consistency with 國字標準字體, I hope Source Han project will accept this request (as many in the Chinese community already has voiced out in the past time). The same thing already happened in v2.000 with 辶 component, so I don't see any reason why this can't be implemented.