Update data models

[matt852]

Added some new variables from recent PR conversations to the data models. I'm looking to discuss these and have a conversation as to their validity.

[mjbear]

Removing trailing period from INNER_VLAN

Suggested change

	| `INNER_VLAN`. | numeric VLAN identifier; used instead of VLAN, VLANID, or TAG |
	| `INNER_VLAN` | numeric VLAN identifier; used instead of VLAN, VLANID, or TAG |

[mjbear]

Removing trailing period from OUTER_VLAN

Suggested change

	| `OUTER_VLAN`. | numeric VLAN identifier; used instead of VLAN, VLANID, or TAG |
	| `OUTER_VLAN` | numeric VLAN identifier; used instead of VLAN, VLANID, or TAG |

[mjbear]

Update description to flow/read better.

Suggested change

	| `ACCESS_GROUP_IN` | access group for IPv4 addresses, inbound |
	| `ACCESS_GROUP_OUT` | access group for IPv4 addresses, outbound |
	| `ACCESS_GROUP_V6_IN` | access group for IPv6 addresses, inbound |
	| `ACCESS_GROUP_V6_OUT` | access group for IPv6 addresses, outbound |
	| `ACCESS_GROUP_IN` | inbound access group for IPv4 addresses |
	| `ACCESS_GROUP_OUT` | outbound access group for IPv4 addresses |
	| `ACCESS_GROUP_V6_IN` | inbound access group for IPv6 addresses |
	| `ACCESS_GROUP_V6_OUT` | outbound access group for IPv6 addresses |

[mjbear]

There are some more detailed descriptions I put in the data model on PR #2241

I have been thinking about opening an issue to discuss a few items rather than discuss it on 2241.

For example type checking (is it a list or a string) is simple and minimizes capture group sprawl. (I recognize the breaking behavior and there may likely be opposition. And certainly not something I'm immovable on.)

💡 Where capture group name normalization helps the community the most is when working with 2+ platforms for the same command(s)/protocol(s) in the same script, playbook, etc. (This is the reason I started some normalization.)