Small refactor to remove inverted dependencies in Albany

[bartgol]

I thought about the issue of circular dependencies in Albany. The main issue is with the various factories (or factory-like) classes in Albany, which require knowledge about the subpackages.

After thinking about it, I think we should do something like this:

1. For each factory type XYZ (e.g., ProblemFactory), create a base abstract class (e.g. ProblemFactoryBase), and have only the "generic" Albany objects created in the 'default' albany factory.
2. Packages can have their own factory, which inherits from the base one.
3. Most of the creation happens in the application. So let's make the factories 'settable' in the application, with the default one always present.
4. In the Main_.cpp file we add all factories, including LandIce ones. This is ok, since Main_.cpp is not in AlbanyLib, so it can depend on LandIce too.
5. Similar to 4, the mpas interface has to set LandIce factories in the application
6. Probably need to modify a tad also the SolverFactory (which is probably good anyways, especially since we pruned some stuff and maybe the solver factory can be cleaned a bit).

@mperego @gahansen @ikalash @jewatkins I'm planning to do something on this side, if you're ok with it. Should be pretty quick.

[jewatkins]

This sounds good to me.

[mperego]

Yes, it would be nice to have the Package (even if now it's only one) separated from the core files.. if it doesn't take long.

[ikalash]

I'm ok with these changes.

[gahansen]

I'm also OK with this - sounds like the right way to go.

[bartgol]

Can we make STK a required dependency of Albany? Now that SCOREC is out of the picture, STK meshes are the only option...

[gahansen]

I vote yes.

[jewatkins]

Seems okay to me. It shouldn't be too hard to make it optional again if we decide to introduce some other discretization down the line. Or were you thinking of getting rid of the entire discretization abstraction?

[bartgol]

No, I'll leave the abstraction, with the factory and everything. But since we only have STK, it seemed silly to make it 'optional'.

[gahansen]

In conversations with @bartgol, we decided to remove STK Adapt, Rebalance, and Percept as part of this small refactor. As such, this issue replaces and supercedes issue #37 - I am closing the earlier issue.

[bartgol]

@gahansen I ended up pruning the stk_adapt stuff, but kept the stk rebalance stuff. I believe we are using it together with zoltan when we need to redistribute the mesh, which, I think happens for instance when we load a stk mesh serially, and distribute it among ranks on the fly.

In #37 Dan said the rebalance stuff is supported directly in SEACAS. I think for now we can keep the snapshot of the old stk_rebalance in Albany (which I think works, at least for the serial mesh thingy). When time permits, we should see if we can directly use SEACAS, and purge the percept directory completely.

[gahansen]

@bartgol sounds great to me. I'm familiar with the stk rebalance logic, I'll volunteer to do what @ibaned suggests - I'll open a new issue to replace the current approach with Ioss. I want to look around in Ioss again anyway to see what I can use for block data support these days.

[bartgol]

To be clear, I think this is not a priority for now. We should probably focus on the block discretization stuff first.