x86/entry: Simplify #VC entry stack mappings

tl;dr: The SEV VC exception stack setup is needlessly complicated.
Simplify it and make it more consistent. Note the modest code
removal.

== Background ==

The "VC" and "VC2" stacks are used by AMD SEV systems.

Today, they:

Consume physical space: CONFIG_AMD_MEM_ENCRYPT=y
 Consume virtual space: Always
            Are mapped: when CC_ATTR_GUEST_STATE_ENCRYPT==1

The virtual space isn't a problem. The physical space consumption
isn't easily fixable and wastes 4 pages per CPU. No biggie. The
mapping does not cost anything either way. It needs to be present
for SEV, but doesn't hurt if it is present elsewhere.

I'm not sure the virtual space consumption was on purpose though.
I suspect it was just missed when VC_EXCEPTION_STKSZ was
introduced.

== Problem ==

The "VC" and "VC2" stacks needlessly and confusingly consume
virtual space even when disabled at compile time.

The conditionals around their runtime setup are also needlessly
complicated.

== Solution ==

In the end, neither the "VC" nor "VC2" need virtual or physical
allocation when CONFIG_AMD_MEM_ENCRYPT=n. Size their "ESTACKS"
entries directly on VC_EXCEPTION_STKSZ, so they will be empty
when AMD memory encryption is disabled.

Remove all the explicit checks before doing setup of
cea_map_stack(VC|VC2). When AMD memory encryption is disabled, the
stacks will be zero-sized and cea_map_stack() will do nothing. When
enabled, the stacks will be mapped whether the CPU supports AMD memory
encryption or not. But, these unused stacks are harmless, just like
mapping the NMI stack is harmless on systems without NMIs.

In the end, the VC/VC2 management looks like this:

Consume physical space: CONFIG_AMD_MEM_ENCRYPT=y
 Consume virtual space: CONFIG_AMD_MEM_ENCRYPT=y
            Are mapped: CONFIG_AMD_MEM_ENCRYPT=y

The dumpstack_64.c is a wee bit of collateral damage. The
estack_pages[] range initializer can not handle a 0-page exception
stack. #ifdef it out.

Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>